Alterator/role-setup: различия между версиями
Строка 25: | Строка 25: | ||
=== Десктоп === | === Десктоп === | ||
Цель: Получить готовую к использованию рабочую среду на десктопе. | Цель: Получить готовую к использованию рабочую среду на десктопе. | ||
Функциональность: | Функциональность: | ||
# Управление пользователями | # Управление пользователями |
Версия от 16:54, 4 августа 2008
На этой страничке предлагается описывать типичные тематические роли для альтератора, а также что хотелось бы иметь.
Шаблон
- Название роли.
- Описание необходимого функционала. Т.е. ответ на вопрос что должен делать альтератор в данной роли в целом.
- Список используемых модулей альтератора
- Описание каждого модуля и что должен делать каждый модуль
- Описание взаимосвязи и взаимодействия вышеперечисленных модулей между собой
Программа установки
Цель: Установить ОС на компьютер. При этом проходятся такие этапы установки:
- Сбор сведений.
- На этом этапе загружается ядро, и производится сбор сведений у пользователя: Выбор языка, разметка диска, куда и как установить загрузчик, пароли и пользователи. настройка сети и т.д. все что идет до установки базовой системы. Результатом работы этого этапа является получение autoinstall.shm. В конце пользователю показываются все собранные данные и задается вопрос: - "Произвести установку?" Никаких изменений на диске на этом этапе не производится.
- Установка. На этом этапе запускается по ранее полученному сценарию установка.
- Настройка на тематическую роль в целом и каждый сервис в частности. После установки на этом этапе предлагается выбрать роль компьютера. Пользователь может отказаться от выбора, и тогда этот выбор нужно предложить при первом заходе в альтератор. В зависимости от выбранной роли производится настройка.
Преимущества разделения сбора сведений и самой установкой вижу такие: 1. Экономит время. Не нужно ждать пока выполнится каждый шаг и следить а закончился ли он? 2. Гарантирует полностью рабочий autoinstall.scm.
Десктоп
Цель: Получить готовую к использованию рабочую среду на десктопе.
Функциональность:
- Управление пользователями
- Пользователи и группы
- Аутентификация
- Локаль, раскладка клавиатуры
- Управление программами
- Обновления
- Установка и удаление программ
- Выбор источников
- Сеть
- Общие параметры: сетевое имя, DNS, прокси-сервер
- Настройка параметров подключения по Ethenet, WiFi, GPRS, PPP, PPPoE, PPTP
- Сетевые службы
- Общие ресурсы (NFS, Samba)
- Сетевой экран (брандмауэр)
- Система
- Информация о системе (в том числе HCL)
- Загрузка (LILO)
- Разделы жёсткого диска
- Запущенные службы
- Дата и время
- Оборудование
- Установка оборудования
- Принтеры
- Сканеры
- Графическая система
Офисный сервер (интранет-сервер)
Цель: Использование альтератора для администрирования отдельного сервера в рамках одной организации На сервере используются:
- Почта: postfix+dovecot+amavis+clamav+spamassassin
- Файловый сервер: samba, ftp, ntfs
- Http сервер: apache+php или nginx+php
- Прокси сервер: squid+havp
- Севрвер времени: openntp
- Сервер базы данных: MySQL, PostgreSQL
Здесь нужно разделить первоначальную настройку и само администрирование.
Первоначальная настройка и получение работоспособного сервера сервера должна осуществляться полностью в автоматическом режиме. Т.е. от пользователя требуется только указать какую роль выполняет данный сервер и получить работоспособный, настроенный сервер. Этот этап может выполняется как в инсталяторе после выбора соответствующей роли, так и отдельно уже после установки.
Администрирование уже подразумевает управление всеми этими сервисами. И это должны быть отдельные модули, которые будут предоставлять высокоуровневое управление. Возможно здесь нет необходимости использовать openvz
Терминальный сервер
TODO
Интернет-сервер
Цель: Использование альтератора для администрирования отдельного сервера на площадке провайдера. Несколько расширенная реализация интранет сервер. Используется OpenVZ для респределения сервисов по контейнерам. Также необходим интерфейс управления не только сервисами, но и интерфейс для пользователя, откуда пользователь может управлять своим аккаунтом: сменить пароль, управлять почтой (сортировка, обучение антиспама, вебпочта), хранить свои данные, просматривать свою статистику и т.д.
На сервере используются:
- Почта: postfix+dovecot+amavis+clamav+spamassassin
- Файловый сервер: samba, ftp, ntfs
- Http сервер: apache+php или nginx+php
- Прокси сервер: squid+havp
- Севрвер времени: openntp
- Сервер базы данных: MySQL, PostgreSQL
Сервер хостинг-провайдера
Цель: предоставить средства для управления хостингом. Схема серверов и сервисов для хостинга. Правила которые она должна выполнять:
1.Все сервисы должны выполняться в VPS 2.Один сервис (или логическая связка) — один VPS 3.База пользователей должна быть одна 4.Управление должно осуществляться из одного места 5.Возможность отключить не используемый сервис. Модульная система. 6.Простая система обновлений на всех серверах.
Т.о. для выполнения этих правил схема серверов и сервисов будет такая:
I.Сервер HN. Является носителем VPS. Будем рассматривать его как минимальная структурная единица предоставляющая все сервисы в данном датацентре (ДЦ). При большем количестве серверов в ДЦ возможно перераспределение VPS по носителям. Обязательные VPS какие должны располагаться на HN: 1.VPS служебный. На нем хранится база пользователей и скрипты по управлению. В случае отказа основного сервера может стать мастером для управления. Обычно это один VPS. 2.VPS для хостинга. На нем хранятся пользовательские скрипты. Установлен вебсервер и php. Количество не ограничено. 3.VPS для почты. На нем хранится пользовательская почта и работает MTA+антиспам+антивирус. Количество не ограничено. 4.VPS для mysql. На нем располагаются базы данных пользователей и работает mysql Не обязательные VPS: 5.VPS для java хостинга. На нем установлен tomcat. Количество не ограничено. 6.VPS для PostgreSQL. Располагаются базы для postgresql и работает сервер. Количество не ограничено.
Такая схема дает такие преимущества:
1.Обеспечит безопасность и большую отказоустойчивость. Например, если пользовательские скрипты загрузили 1 VPS, то работоспособность других VPS сохраняется.
2.Легко предоставлять пользователям те настройки которые они хотят. Например часто хотят видеть чтобы php работал как модуль. Разбив пользователей на небольшие группы, мы сможем предоставлять гибкие настройки.
3.Можно в пределах одного ДЦ держать 1 VPS с postgresql т.к. пользователей использующих эту базу не много. Или один почтовый сервер и заботиться о работоспособности одного сервера (проверять в антиспамовских базах и т.д.).
4.Единая база пользователей, единый интерфейс управления всеми пользователями, сервисами и серверами.
Необходимы следующие возможности:
- Административные модули:
- Модуль управления аккаунтами (поиск по домену, имени; блокировка, бэкап, трансфер, управление доступом к ssh, mysql, смена пароля, контактного e-mail).
- Модуль создания квот на ресурсы (дискового пространства, количества баз, количество доменов, алиасов к домену, возможность предоставления ssh доступа и т.д.)
- Пользовательские модули:
- Модуль управления доменами (создание, удаление, парковка, дополнительные домены и т.д.)
- Модуль управления дополнительными почтовыми аккаунтами для данного домена.
- Модуль управления базами для mysql и pgsql (модуль должен создавать/удалять пользовательские базы согласно квотам)