Это старая версия zonemng/SRS3 за 2008-07-06 21:24:13..
Zonemng Software Requirement Specification
Страница, вызываемая из Действия, пока не существует.(/zonemng / SRS 3 / Определения?)
Сокращения
ПС – Пользователь Системы UC – Use Case
Общее описание
Цель
Основными целями проекта является создание системы, которая позволит:
управлять зонами ОС Solaris 10;
автоматизировать управление хостингом на базе ОС Solaris 10;
в некоторой степени упростить управление компьютером, работающим под ОС Solaris 10.
ОС Solaris 10
Причины, по которым была выбрана ОС Solaris 10:
наличие встроенной системы виртуализации – зон, и системы управлениями ресурсами компьютера;
официальная поддержка Sun.
Схожие програмные продукты
Parallels Plesk – система автоматизации хостинга. Parallels Virtuozzo – система виртуализации для Linux – аналог зон в Solaris 10. Solaris Container Manager – система для облегчения управления зонами в ОС Solaris.
Роли (система управления правами)
Краткое описание Ролей и их места в Системе в целом:
1) Administrator (root Сервера)
управляет Сервером в целом.
управляет Профилями ПС с ролью Zone-reseller.
может существовать только один Профиль ПС с такой ролью. В дальнейшем может быть рассмотрена возможность создания алиасов – Профилей ПС, дублирующих всю информацию Профиля ПС за исключением пары Логин-Пароль. Так же может быть рассмотрена возможность создания нескольких Профилей ПС с ролью Administrator, но только после получения работоспособного прототипа системы, т.к. в данный момент непонятны преимущества использования нескольких Профилей ПС этой роли, зато видны значительные усложнения в реализации и логике работы самой программы.
2) Zone-reseller (root Сервера с ограниченными правами)
обладает некоторым количеством Ресурсов: см. Ресурсы.
производит некоторые действия над зонами: создает, редактирует, удалят, привязывает к зонам Ресурсы.
обладает root-овым доступом к привязанным к нему зонам
управляет сервисами внутри своих зон.
управляет профилями End-user'ов внутри своих зон.
4) End-user (user внутри зоны)
пользуется сервисами, которые предоставил Zone-owner
Профиль Пользователя Системы
Профиль ПС в первую очередь включает в себя:
1. Логин и Пароль, знание Пользователем Системы которых является достаточным условиям для ассоциации Профиля ПС с этим Пользователем Системы (процесс Авторизации).
2. Статус профиля ПС и флаг приостановки Профиля ПС – означает временную невозможность авторизоваться в Системе, а также возможную приостановку всех подчиненных Профилей ПС, использованных сервисов и зон.
3. Персональная информация ПС – имя, фамилия, e-mail, дата создания, адрес, телефон, факс, язык.
В зависимости от выбранного языка меняется локализация приложения-клиента.
4. Роль, определяющая дальнейшее содержание профиля, а также действия, которые может совершать Авторизованный ПС.
Далее, содержание профиля зависит от Роли:
1) Zone-reseller
Родительский Профиль ПС с ролью Administrator
Подчиненные Профили ПС с ролью Zone-owner
Подчиненные Зоны
Лимиты (некоторые ресурсы)
2) Zone-owner
Зоны
Подчиненные Профили ПС с ролью End-user
Родительский Профиль ПС с ролью Zone-reseller
3) End-user
Родительский Профиль ПС с ролью Zone-owner
Доступные сервисы, и для каждого сервиса – свои настройки
Лимиты (ресурсы и сервисы)
Лимиты
Пользовательские лимиты подразделяются по Ролям – Авторизованый ПС соответствующей роли имеет соответствующие лимиты.
1) Zone-reseller
Ресурсы Сервера:
Процессоры:
какие именно (для многопроцессорной системы)
долевая нагрузка
Оперативная память
Файловая квота
Сетевые интерфейсы
физические сетевые интерфейсы
для каждого физического сетевого интерфейса – диапазон IP-адресов
для каждого физического сетевого интерфейса – максимальный трафик (входящий/исходящий) за определенный период
опционально: для каждого физического сетевого интерфейса – максимальная пропускная способность
Максимальное количество подчиненных зон
Максимальное количество подчиненных Профилей ПС роли Zone-owner
не понятно, если ZR создал зону и знает ее пароль, то он может отдать комуто этот пароль отдав т.о. зону, не создавая дополнительного пользователя ZO. тогда какой смысм в ограничениях на максимальное количество ZO
VT: Ресурсы типа «количество ZO» и «количество зон» – это разные ресурсы. Реселлер может поступить как описано выше, но тогда такие "Zone Owner'ы?" теряют все премущества использования нашего web-клиента
2) Zone-owner
Все лимиты для Профилей ПС этой роли задаются лимитами зон, находящихся в подчинении.
3) End-user
Дисковая квота для домашней директории
Максимальный сетевой траффик за месяц
Все остальные лимиты задаются настройками Сервисов
Также существуют лимиты (в общем случае ресурсы) на зону: Определится с лимитами более точно
Процессоры:
какие именно (для многопроцессорной системы)
долевая нагрузка
Оперативная память
Файловая квота
Виртуальные сетевые интерфейсы – для каждого: диапазон IP-адресов, максимальная пропускная способность, максимальный трафик (входящий/исходящий) за месяц
Максимальное количество Профилей ПС роли End-user, привязанных к зоне.
непонятно абсолютно аналогично лимитам для ZR VT: Здесь и правда не совсем понятно как технически ограничить число пользователей зоны. Видимо придеться убрать этот ресурс и соответственно ограничение на число EU. B: еще вариант – не давать рутового доступа для пользователей типа Zone-owner, тогда ограничение будет иметь смысл; можно еще сделать два варианта по выбору для каждого профиля владельца зоны – предоставить/ограничить рутовый доступ, тогда все нормально будет
Шаблоны
В системе планируется много мест, в которых будет происходить создание какого-то объекта (пользователя, зоны, аккаунта веб-сервера, и т.д.). Пунктов, которые нужно заполнять при создании объекта достаточно много при тонкой настройке. Также возможны некоторые пре- и пост- действия (после создания end-user аккаунта создать аккаунт для него в зоне с веб-сервером + настроить виртуальные хосты в случае апача). Для облегчения типовых задач – создание некоторого сценария создания + автозаполнение полей форм.
Обязательно необходимо реализовать шаблоны:
Зоны
Пользователя для каждой роли
Набора лимитов
Шаблоны впоследствие будут специфицированы более точно, а их реализация будет происходить в последнюю очередь.
Общие требования
Протокол взаимодействия Клиента и Агента
В качестве основного протокола взаимодействия Клиента и Агента должен быть XML-RPC.
Клиенты
Два типа Клиентов:
1. Web-приложение (вероятно PHP5)
основная цель – мобильность – возможность запустить клиент там где есть браузер и интернет, и условия не позволяют установить настольное приложение (например: отсутствие прав для запуска сторонних приложений, блокировка фаерволами).
должен работать как при наличии Java Script?, так и при его отсутствии (требование мобильности)
интерфейс должен быть унифицирован с Plesk
при наличии Java Script?, желательно использовать AJAX-технологии, как в Plesk'e
должно работать во всех версиях популярных браузеров (IE 5/6/7, Firefox, Opera 9) максимально одинаково
максимально возможная скорость реакции на действия пользователя
минимально возможный потребляемый траффик
в итоге:
максимально толстый клиент, с большинством предварительных проверок на стороне пользователя
желательно использовать некоторый бинарный протокол для минимизации траффика (пока что можно остановиться на сжатии XML-RPC запросов)
Общие требования:
клиенты должны быть максимально простыми для повседневного типового использования, интуитивно понятны, не перегружены лишними и редкоиспользуемуми возможностями, какие есть в SCM.
но в тоже время должна быть возможность тонкой настройки по требованию.
мультиязычность – должны быть простые средства для локализации клиента (для web-клиента – см. Plesk); в базовом варианте должно быть как минимум два языка – английский и русский.
Установка, конфигурирование, отладка:
Должны существовать утилиты для обслуживания системы:
Инсталятор Агента на Solaris. Должен включать в себя утилиту для создания пользователя-администратора и смены его пароля.
Инсталятор web-клиента на web-сервер.
Функциональные требования
Неавторизованный ПС
Для следующих UC необходимым требованием является, что ПС является Неавторизованным ПС. 1) Login (Авторизация) Предусловие: То, что ПС является Неавторизованным ПС по сути означает, что либо ПС только что запустил Клиент, либо что ПС применил Logout Сценарий:
1. Запрашиваются логин и пароль. Пароль не должен отображаться на экране в явном виде.
2. Пользователь нажимает кнопку входа в систему
3. Клиент производит начальную проверку введенных данных – является ли логин и пароль введенные пользователем корректными логином и паролем в Системе. Если не являются – происходит возврат на шаг 1, причем поле логин должно быть автоматически заполнено изначально введенными ПС на 1-м шаге данными. Если являются – отсылается запрос Серверу, проверяется существование Профиля ПС с такими логином-паролем. Если проверка завершилась успешно – устанавливается привязка ПС (точнее Клиента) к этому Профилю ПС. В противном случае – переход на шаг 1 с сообщением об некорректном логине и пароле и автозаполнением логина старым значением. Дополнительные пожелания:
Все сообщения об ошибках должны выглядеть одинаково.
Должна быть в некотором виде система защиты от подбора пароля – например максимальное число попыток входа с одного IP-адреса. При большом количестве неудачных попыток входа каким-либо образом должны быть отправлено сообщение администраторам системы.
Авторизованный ПС
Для следующих UC необходимым требованием является, что ПС является Авторизованным ПС. 1) Logout (Выход из Системы) Описание: текущий ПС становится Неавторизованным ПС и переводится на страницу авторизации.
2) Смена пароля Описание:
1.Запрашиваются текущий пароль, новый пароль и подтверждение нового пароля.
2. Если введеный текущий пароль не является паролем текущего Профиля ПС – переход на шаг 1 с сообщением о том что старый пароль неверный.
3. Проверяются новый пароль и подтверждение на корректность и совпадение. В случает неудачи – соответствующие сообщения об ошибке.
4. Происходит изменение пароля текущего Профиля ПС на новый.
По ролям
Для следующих UC необходимым требованием является, что ПС является Авторизованным ПС и Профиль ПС имеет роль, указанную в заголовке.
1) Просмотр доступных сервисов Идея:
Просмотр доступных сервисов (т.е. включенных для данного пользователя) в виде списка, с возможностью быстрого перехода к «Настройки/использование сервиса» каждого конкретного сервиса.
2) Настройки/использование сервиса Примечание:
Что именно должно быть реализовано в данном пункте определяется для каждого сервиса по своему. Для дополнительной информации см. Service SRS.
Лимиты
1) Просмотр своих лимитов. Идея:
Просмотр потребления основных своих ресурсов и соответствующих им лимитов Описание:
Должны отображаться следующие поля:
дисковая квота: доступно/использовано
сетевой траффик за месяц: доступно/использовано
UC роли Администратор