Брацко Облако

Брацко Облако (CNM Cloud; далее то тексту -- Облако) -- это технологические ресурсы Брацкой Школы (здесь и далее то тексту -- Школы). Облако представляет собой совокупность программного обеспечения и поддерживающей его материальной части.

Общие положения

Основные цели

Технологические ресурсы призваны поддерживать людей, которые:

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

Дополнительные цели

Кроме того, Облако может быть полезно:

• тем выпускникам, которые решат организовать или продвинуть свои собственные предприятия,
• тем предприятиям, которые нанимают кадры найденные, подготовленные и/или сертифицированные с использованием Облака.

Обзор обеспечения

Ярус	Название	Предназначение	Технология	Веб‑адрес
Инфраструктура	Фермы	Поддержка Связующего обеспечения и Пользовательских приложений	OpenStack	Спрятан
Связующее обеспечение	Оплёт (ядро)	Управление регистрацией, идентификацией и авторизацией доступов пользователей	Yii (custom code)	kabina.bskol.com
	Идентификация	Получение данных от ядра и взаимосвязь с пользовательскими приложениями	WSO2 IS	Спрятан
Пользовательские приложения	Бачка	Размещение видео файлов	AVideo	backa.bskol.com
	Вебка	Администрация вэб-сайтов	WordPress	vebka.bskol.com
	Жици	Организация видео- и аудио-конференций	Jitsi	jitsi.bskol.com
	Крынка	Работа разработчиков над проектами с установленным service desk приложением для сбора информации по проблемам и хранение исходных кодов уникального программного обеспечения	GitLab	krynka.bskol.com
	Пошта	Электронная почта	Roundcube	posta.bskol.com
	Правка	Открытый источник знаний и, одновременно, работа для новичков	MediaWiki	pravka.bskol.com
	Связка	Полезные контакты	SuiteCRM	svazka.bskol.com
	Сетка	Социальная сеть	HumHub	setka.bskol.com
	Справа	Административный учёт, электронная коммерция (Careerprise Shop) и работа персонала над проектами	Odoo	sprava.bskol.com
	Учебка	Бесплатные учебные курсы	Moodle	ucebka.bskol.com
	Арендованное обеспечение
Эксперементальные приложения	Campus	Учебные курсы VIT	OpenEdX	campus.vit4all.com
	Agile	Практика для VIT курсов по Agile software	Taiga	agile.vit4all.com
	Project	Практика для VIT курсов по project management software	ProjecQtOr	project.vit4all.com
	Redmine	Практика в Redmine для VIT курсов по project management software	Redmine	redmine.bskol.com

Общие требования

Основная вики-страница: Требования к приложениям Брацкого Облака

Требования к приложениям описаны на вики-странице Требования к приложениям Брацкого Облака.

Технологические ярусы

Облако включает в себя три яруса программного обеспечения:

1. Инфраструктуру,
2. Связующее обеспечение и
3. Пользовательские приложения.

Брацки Фермы (инфраструктура)

Основная вики-страница: Брацки Фермы

Архитектура облачной инфраструктуры не определена. Ранее использовался OpenStack. Скорее всего, когда работа Школы войдёт в привычный режим, инфраструктура должна состоять из некой комбинации частного и общественных облаков.

В настоящее время, используется пять виртуальных частных серверов (virtual private server; VPS):

1. Три арендованы у Contabo; два сервера и отдельное дисковое пространство для резервных копий располагаются в Миссури, США, один -- в Германии;
2. Два арендованы у DigitalOcean; один располагается в Нью-Йорке, США, один -- во Франции.

Мониторинг

Мониторинг систм включает мониторинг работы как вычислительных серверов, так и приложений. Планируется использовать внутренние функции установленных приложений и рассмотреть отдельные приложения, такие как Zabbix и Nagios.

Почтовый сервер

Команда планирует поднять highload мультидоменный почтовый сервер. Компетенций существующей команды хватает для настроек поддоменов и веб-серверов, но не для выбора и подготовки к эксплуатации. Количество пользователей не определено -- все, кто имеет право на почту, должен её иметь. Проблемы с дисковыми пространствами будут решаться отдельно.

Требуется:

1. Выбрать, установить, настроить, провести нагрузочное тестирование, отмониторить продакшн и откоректировать параметры такого решение для почты, которое бы дружило с нашим WSO2 IS, через который идёт управление пользователями. Будет установлен пакет iRedMail, который включает в себя Postfix, Dovecot, Roundcube. Когда Облако строилось на OpenLDAP, был найден подрядчик, требования которого были: 1. Что бы у всех пользователей было заполнено поле mail 2. Новый пользователь vmail (пароль скажут после установки пакета iRedmail) 3. Поле для квоты. Также обсуждался безопасный тунель между сервером почты и сервером OpenLDAP. Найденный подрайдчик считал, что лучшее решение -- это использование VPN, чтобы и OpenLDAP, и Dovecot виртуально были бы в одной сети. Авторизация почтового сервера идёт через Dovecot. Другой специалист называл такое решение идиотским. После решения о переходе с OpenLDAP на WSO2 IS подрячиков не искали.
2. Задокументировать решения и настройки.

Оплёт (федеративная служба)

Основная вики-страница: Оплёт

Оплёт -- это то служебное программное обеспечение, которое собирает и Инфраструктуру Облака, и его Пользовательские приложения в единую систему. Оплёт представляет собой связующее программное обеспечение, которое может обеспечивать все вне зависимости от их расположения в системе, прежде всего, услугами по идентификации всех пользователей Облака, регистрации новых пользователей, определение ролей пользователей, авторизации их доступов и так далее.

Оплёт состоит из:

1. Ядра, который представляет собою систему управления пользователями, написанную на Yii,
2. Идентификационного сервера, который предоставляет данные ядра всем пользовательским приложениям.

Федерационная идентификация

Пользовательская федерация налаживается на базе WSO2 Identity Server. До лета 2021, она строилась на OpenLDAP, а до 2018 года -- на SimpleSAMLphp.

1. Перевести основную идентификацию и авторизацию с OpenLDAP на WSO2 Identity Server в рамках проекта Перевод Оплёта на WSO2 IS.
2. В тех приложениях, которые работают с OpenLDAP, на регистрационных страницах оставить кнопку "LDAP login". Альтернативно, эту кнопку можно разместить на регистрационной странице WSO2 IS.
3. Разрешить проблему ролей. По окончании курса Учебка (Moodle) должна отдавать информацию Оплёту, тот должен назначать новую роль и отдавать эту роль в WSO2 Identity Server, а WSO2 Identity Server -- распространять по всем приложениям. Ранее эту проблему пытались решать с OpenLDAP. Всё решалось пока не сломались на проблеме изменения ролей -- OpenLDAP принимал только одну роль и далее не менял её.
4. Проверка SSO. Более 3х десятков пользовательских приложений включено в "Облако" и, заходя в каждое из них, сейчас пользователь не должен логиниться отдельно. Теоретически, SSO -- это родная функция WSO2 Identity Server, но, после перехода с OpenLDAP на WSO2 Identity Server, каждое приложение должно проверяться.

Пользовательские приложения

Пользовательские приложения -- это приложения для конечных пользователей.

Бачка

Основная вики-страница: Брацка Бачка

Брацка Бачка -- это средство загрузки, хранения и просмотра видео-материалов. Видео построено на основе программного обеспечения AVideo. Часть курсов Бачки, например, видео-материалы курса Брацки Техобзор, может быть доступна без оплаты всем посетителям сети Интернет. Доступ к некоторым материалам может предоставляться на коммерческой основе.

Вебка

Основная вики-страница: Брацка Вебка

Брацка Вебка -- это сеть вэб-сайтов Брацкой Школы, которые представляют Школу в сети Интернет. Вэб-сайты построены на основе программного обеспечения WordPress и доступны для просмотра бесплатно 24 часа в день 7 дней в неделю любому посетителю сети Интернет.

Жици

Основная вики-страница: Брацки Жици

Брацки Жици -- это инструмент Брацкой Школы для организации видео- и аудио-конференций. Жици построены на основе программного обеспечения Jitsi и организованы кластером. Жици доступны для любых участников конференций, но начинать сессии могут только те, кто зарегистрирован в Оплёте.

Крынка

Основная вики-страница: Брацка Крынка

Брацка Крынка -- это средство для работы над проектами, построенное на основе программного обеспечения GitLab и доступное исключительно администраторам Брацкой Школы и авторизованным ими разработчикам программного обеспечения. Доступ к Крынке осуществляется исключительно по PKI.

Пошта

Основная вики-страница: Брацка Пошта

Брацка Пошта -- это электронная почта, построенная на основе программного обеспечения RoundCube и доступная исключительно сотрудникам Брацкой Школы.

Правка

Основная вики-страница: Брацка Правка

Брацка Правка -- это открытая база знаний Брацкой Школы, построенная на основе программного обеспечения MediaWiki и доступная для просмотра бесплатно 24 часа в день 7 дней в неделю любому посетителю сети Интернет.

Связка

Основная вики-страница: Брацка Связка

Сетка

Основная вики-страница: Брацка Сетка

Справа

Основная вики-страница: Брацка Справа

Брацка Справа -- это средство управления людскими и материальными ресурсами предприятия, построенное на основе программного обеспечения Odoo. Часть Справы, например, открытые документы предприятия, может быть доступна всем посетителям сети Интернет. Другая часть, например, данные клиентов предприятия, доступна исключительно тем сотрудникам Брацкой Школы, которые подписали соглашение о неразглашении конфиденциальной информации.

Учебка

Основная вики-страница: Брацка Учебка

Брацка Учебка -- это средство организации учебных курсов и сертификационных программ, построенное на основе программного обеспечения Moodle. Часть курсов Учебки, например, Брацка Вводка, может быть доступна без оплаты всем посетителям сети Интернет. Доступ к некоторым курсам может предоставляться на коммерческой основе.

Данные в Облаке

Базы данных

1. Наибольшая часть пользовательских приложений использует базы управления данными на основе MariaDB Server. Администраторское приложение PhpMyAdmin используется для администрирования каждого из них.
2. Для управления пользователями, Оплёт также использует MariaDB Server. Однако та часть Оплёта, которая работает с другими приложениями и построена на базе сервера WSO2 IS, задействует три базы H2 DBMS.
3. Базы управления данными на основе PostgreSQL вовлечены в работу Брацкой Справы.

Стойкость баз

Следующая архитектура используется для обеспечения отказоустойчивости (high availability) Облака:

• Все пользовательские приложения дублируются -- копии каждого из них установлены как минимум на трёх вычислительных серверах в разных центрах.
• Базы данных разных установок одного и того же приложения синхранизуются. Таким образом, обращаясь к любому из них, пользователь получает аналогичные данные и результаты вычислений.
• Когда пользователь хочет обратиться к приложению, пользователь направляется на распределитель нагрузки (load balancer). Распределитель нагрузки постоянно связывается со всеми установками приложений, чтобы знать, какие из них находятся в наличии. От распределителя нагрузки, пользователь перенаправляется к той установке, которая работоспособна и доступнее для конкретного пользователя. Если какая-то из установок выходит из строя, пользователь этого не должен заметить. Как только распределитель нагрузки замечает отсутствие какого-либо ресурса, он запускает механизм отладки.

Облако состоит из нескольких кластеров и его стойкость складывается из стойкости отдельных кластеров. Все они должны быть переделаны в отказоустойчивые (high-availability cluster). Для тех пользовательских приложений, которые используют MariaDB, строится кластер на основе MariaDB MaxScale. Для других, скорее всего, решения будут строиться на основе HAProxy. Также рассматриваются решения для кластеров типа Linux-HA на основе heartbeat.

Базы в кластерах

Ярус	Название	Основное ПО	ПО базы данных	Кластер
Инфраструктура	Фермы	OpenStack	Все остальные
Связующее обеспечение	Оплёт (ядро)	Yii	MariaDB Server	Кластер Оплёта
	Идентификация	WSO2 IS	H2 DBMS
Пользовательские приложения	Бачка	AVideo	MariaDB Server	Кластер MariaDB
	Вебка	WordPress
	Жици	Jitsi	Отсутствует	Кластер Жици
	Крынка	GitLab	PostgreSQL	Кластер PostgreSQL
	Пошта	Roundcube
	Правка	MediaWiki	MariaDB Server	Кластер MariaDB
	Связка	SuiteCRM
	Сетка	HumHub
	Справа	Odoo	PostgreSQL	Кластер PostgreSQL
	Учебка	Moodle	MariaDB Server	Кластер MariaDB
	Арендованное обеспечение
Эксперементальные приложения	Campus	OpenEdX
	Agile	Taiga software
	Project	ProjecQtOr

Аварийное восстановление

Надо создать инструкцию по восстановлению в случае аварии.

Географическая доступность

Говоря о DNS, IP и DNSSEC, есть несколько доменных имён, но пока речь идёт о двух основных -- cnmcyber.com для англоязычных пользователей и bskol.com для русскоязычных:

• Домены зарегистрированы на GoDaddy; nameservers расположены там.
• Система управления пользователями, Оплёт, сейчас расположена на одном VPS (они зовут их "дроплетами") DigitalOcean. Есть план добавить load balancer и перевести систему на кластер. Планов уезжать с DigitalOcean нет.
• Основные пользовательские приложения расположены на трёх VPS contabo.de. VPS объединены в кластер синхронизированной распределённой базой. Есть план добавить или заменить один VPS железом на hetzner.de с установкой proxmox.

Надо:

1. проверить существующие и создать нехватающие DNS и, возможно, новые DNSSEC записи. DNSSEC не является критичной -- может быть отлажено только для какой-то части зон DNS. Проект Школы -- учебный, нам важно иметь разные вещи для того, чтобы показывать ученикам.
2. изучить возможность Dynamic DNS (DDNS) или виртуальных DNS.
3. IPv6. В данный момент используется IPv4 и есть план разобраться с более новым протоколом. Судя по некоторым публикациям, IPv6 решит проблему отказоустойчивости в части перенаправления трафика.
4. Virtual IP address. Есть необходимость разобраться с виртуальными адресами. Digitalocean предлагает floating IP address, который можно устанавливать на те дроплеты (VPS), которые расположены в одном датацентре. Hetzner.de предлагает failover IP, хотя с ними надо разобраться. Не похоже, что Contabo предлагает что-то вроде этого.
5. В случае, если виртуальный IP не возможен, есть практика направления IP на load balancer -- какие плюсы и минусы у этой практики?
6. Есть предложение, чтобы пользователь работал с тем приложением, которое более доступно для этого пользователя. DNS Anycast, DNS Geocast, и аналогичные распределительные системы не установлены -- каждое пользовательское приложение установлено только на одном VPS. Есть план продублировать приложения и отправлять пользователя на тот сервер, который наиболее доступен конкретному пользователю.

Интеграция данных

1. Сейчас, база каждого пользовательского приложения установлена на трёх нодах и синхронизована через Кластерное копирование. Есть план сделать одну распределённую базу и интегрировать её в Оплёт с тем, чтобы базы приложений забирали данные оттуда. В качестве интеграционного решения серъёзно рассматривается WSO2 Enterprise Integrator. Этот интегратор работает и как ESB, и платформа для микросервисов. В качестве распределонной базы один специалист рекоммендовал NoSQL -- Apache Cassandra. Другой вариант -- распределённую SQL типа CockroachDB.
2. Наиболее приоритетная задача -- создать архитектуру базы клиентов. Сейчас клиенты учитываются в нескольких независимых приложениях. Они имеют CRM модули, которые призваны учитывать работу с клиентами, которые могут является, но скорее всего не являются пользователями. Надо создать базу, в которую каждое приложение заливало новые данные и брало старые. Предложение заключалось в общей master базе, информация в которую может вбиваться с любого приложения, но отображаться в зависимости от её публичности.
3. Есть также предложение создать собирать данные с различных приложений и хранить их в NoSQL базе. Ранее обсуждалась единая неосновная база данных для всей системы. Разговор шёл о комбинации Hadoop, ESB Mule и MongoDB. Идея была в сборе данных с разных приложений через ESB Mule, причёсывание их Hadoop'ом и размещение в MongoDB как дополнительной базе данных, откуда они могут браться для для личного кабинета (dashboard) пользователя. То есть, заходя в кабинет, пользователь мог бы в идеале видеть свою активность в разных приложениях и искать по всем системам сразу.
4. Надо стабилизировать загрузку, хранение и использование картинок на MediaWiki. Сейчас они спорадически не загружаются или не отображаются. Например, 7 декабря картинки выбились, перестав отображаться. После клика на редактирование и сохранение, картинки появлялись -- этот сценарий повторялся на нескольких страницах. Затем всё само восстановилось. Аналогичные сбои происходили и раньше. Сама Википедия использует другую схему. Мы рассматриваем перенос картинок в хранилище.

Резервное копирование

В Облаке, к резервному копированию применяется несколько подходов. Копируются приложения и сервера; сохраняются базы и делаются снимки.

• Изначально использовался rsync для копирования файлов, еженедельно полный бэкап и ежедневно incremental бэкап заливались на backup space на Contabo. Была идея использовать rsnapshot для снимков, но эту идею пока не получилось реализовать.
• Весной-летом 2021 года, начались эксперименты с Veeam Agent for Linux, для которого был установлен VNC® Viewer. Это обеспечение позволило копировать полный сервер.

Надо создать:

1. Подробное описание существующей системы.
2. Процедуру проверки надёжности бэкапов.

Кластеры

Связка баз данных приложений с распределителем нагрузки называется кластером. Облако задействует четыре кластера. Каждый кластер поддерживает свойства географической доступности.

Кластер Жици

Основная вики-страница: Кластер Жици

Кластер MariaDB

Основная вики-страница: Кластер MariaDB

Кластер MariaDB связывает те MariaDB Server сервера, которые входят в Облако, но не обслуживают Оплёт. Этот кластер построен на основе трёх MariaDB Galera Cluster в качестве взаимо-синхранизуемых баз данных, MariaDB MaxScale в качестве распределителя нагрузки, а также MariaDB Backup для резервного копирования и MariaDB Replication для поддержки приложений Опытна Облака.

Кластер Оплёта

Основная вики-страница: Кластер Оплёта

Кластер Оплёта построен на HAProxy и, кроме Оплёта, обеспечивает устойчивость распределителей нагрузки остальных кластеров

Кластер PostgreSQL

Основная вики-страница: Кластер PostgreSQL

Развитие ресурсов

Общая стратегия:

1. Поддерживать те технологические ресурсы, которые имеются в наличии.
2. Набирать координаторов проектов для разработки запросов и требований.
3. Искать исполнителей на те Работы в Брацкой Школе, которые относятся к технологическим ресурсам.

Эксперементальные проекты

Есть план либо заменить один VPS железом, либо добавить железный сервер на hetzner.de для решения двух задач:

1. Спроектировать сеть для повышения устойчивости системы.
2. Автоматически создавать виртуальные машины для участников тренингов. Школа будет устраивать тренинги и планирует выдавать ресурсы для практических занятий. После оплаты участником, участник должен получать имэйл со ссылкой на ресурс с логином и паролем. Идеально, ресурс должен быть виртуальной машиной. Если виртуальная машина не получается, можно продумать возможность решения на контейнерах. Специалист считает, что так как контейнер создаётся одной строкой, можно сделать скрипт под Линукс, который будет создавать контейнер из образа и добавлять к нему логин и пароль.

ProxmoxVE -- основное решение, которое рассматривается. Специалист предлагает использовать роутер Microtik, чтобы на proxy сделать два IP адреса, первый использовать для внутренних виртуалок, если они нормально работают, а второй загнать в bridge для внешних серверов и средствами Линукса типа firewall делить тот трафик, который приходит. Кроме того, на том же proxy можно поставить DHCP сервер для раздачи адресов машинам. Другой специалист считает, что безопасных DHCP серверов на рынке нет.

Кластерные проекты

Кластеры Облака решают проблему отказоустойчивости систем.

• Кластер MariaDB
• Управление пользователями осуществляется сейчас с дроплета (VPS) на DigitalOcean (DO). Другой дроплет поддерживает тестировку, но практически не используется. Надо переделать это решение на кластер. Сам DO предлагает load balancer и floating IP address -- эти решения требуют рассмотрения.

Профинансированные проекты кластеров

Работы	MariaDB	PostgreSQL	Жици	Оплёта
Запрос	Достаточно	Достаточно	Достаточно	Достаточно
Требования
Архитектура
Модель
Прототип
Заказ
Производство
Конфигурация
Усовершенствование

Платформенные проекты

Аварийное восстановление===

Надо создать инструкцию по восстановлению в случае аварии.

Географическая доступность===

Говоря о DNS, IP и DNSSEC, есть несколько доменных имён, но пока речь идёт о двух основных -- cnmcyber.com для англоязычных пользователей и bskol.com для русскоязычных:

• Домены зарегистрированы на GoDaddy; nameservers расположены там.
• Система управления пользователями, Оплёт, сейчас расположена на одном VPS (они зовут их "дроплетами") DigitalOcean. Есть план добавить load balancer и перевести систему на кластер. Планов уезжать с DigitalOcean нет.
• Основные пользовательские приложения расположены на трёх VPS contabo.de. VPS объединены в кластер синхронизированной распределённой базой. Есть план добавить или заменить один VPS железом на hetzner.de с установкой proxmox.

Надо:

1. проверить существующие и создать нехватающие DNS и, возможно, новые DNSSEC записи. DNSSEC не является критичной -- может быть отлажено только для какой-то части зон DNS. Проект Школы -- учебный, нам важно иметь разные вещи для того, чтобы показывать ученикам.
2. изучить возможность Dynamic DNS (DDNS) или виртуальных DNS.
3. IPv6. В данный момент используется IPv4 и есть план разобраться с более новым протоколом. Судя по некоторым публикациям, IPv6 решит проблему отказоустойчивости в части перенаправления трафика.
4. Virtual IP address. Есть необходимость разобраться с виртуальными адресами. Digitalocean предлагает floating IP address, который можно устанавливать на те дроплеты (VPS), которые расположены в одном датацентре. Hetzner.de предлагает failover IP, хотя с ними надо разобраться. Не похоже, что Contabo предлагает что-то вроде этого.
5. В случае, если виртуальный IP не возможен, есть практика направления IP на load balancer -- какие плюсы и минусы у этой практики?
6. Есть предложение, чтобы пользователь работал с тем приложением, которое более доступно для этого пользователя. DNS Anycast, DNS Geocast, и аналогичные распределительные системы не установлены -- каждое пользовательское приложение установлено только на одном VPS. Есть план продублировать приложения и отправлять пользователя на тот сервер, который наиболее доступен конкретному пользователю.

Интеграция данных===

1. Сейчас, база каждого пользовательского приложения установлена на трёх нодах и синхронизована через Кластерное копирование. Есть план сделать одну распределённую базу и интегрировать её в Оплёт с тем, чтобы базы приложений забирали данные оттуда. В качестве интеграционного решения серъёзно рассматривается WSO2 Enterprise Integrator. Этот интегратор работает и как ESB, и платформа для микросервисов. В качестве распределонной базы один специалист рекоммендовал NoSQL -- Apache Cassandra. Другой вариант -- распределённую SQL типа CockroachDB.
2. Наиболее приоритетная задача -- создать архитектуру базы клиентов. Сейчас клиенты учитываются в нескольких независимых приложениях. Они имеют CRM модули, которые призваны учитывать работу с клиентами, которые могут является, но скорее всего не являются пользователями. Надо создать базу, в которую каждое приложение заливало новые данные и брало старые. Предложение заключалось в общей master базе, информация в которую может вбиваться с любого приложения, но отображаться в зависимости от её публичности.
3. Есть также предложение создать собирать данные с различных приложений и хранить их в NoSQL базе. Ранее обсуждалась единая неосновная база данных для всей системы. Разговор шёл о комбинации Hadoop, ESB Mule и MongoDB. Идея была в сборе данных с разных приложений через ESB Mule, причёсывание их Hadoop'ом и размещение в MongoDB как дополнительной базе данных, откуда они могут браться для для личного кабинета (dashboard) пользователя. То есть, заходя в кабинет, пользователь мог бы в идеале видеть свою активность в разных приложениях и искать по всем системам сразу.
4. Надо стабилизировать загрузку, хранение и использование картинок на MediaWiki. Сейчас они спорадически не загружаются или не отображаются. Например, 7 декабря картинки выбились, перестав отображаться. После клика на редактирование и сохранение, картинки появлялись -- этот сценарий повторялся на нескольких страницах. Затем всё само восстановилось. Аналогичные сбои происходили и раньше. Сама Википедия использует другую схему. Мы рассматриваем перенос картинок в хранилище.

Мониторинг===

Мониторинг систм включает мониторинг работы как вычислительных серверов, так и приложений. Планируется использовать внутренние функции установленных приложений и рассмотреть отдельные приложения, такие как Zabbix и Nagios.

Postfix/Dovecot/Roundcube===

Команда планирует поднять highload мультидоменный почтовый сервер. Компетенций существующей команды хватает для настроек поддоменов и веб-серверов, но не для выбора и подготовки к эксплуатации. Количество пользователей не определено -- все, кто имеет право на почту, должен её иметь. Проблемы с дисковыми пространствами будут решаться отдельно.

Требуется:

1. Выбрать, установить, настроить, провести нагрузочное тестирование, отмониторить продакшн и откоректировать параметры такого решение для почты, которое бы дружило с нашим WSO2 IS, через который идёт управление пользователями. Будет установлен пакет iRedMail, который включает в себя Postfix, Dovecot, Roundcube. Когда Облако строилось на OpenLDAP, был найден подрядчик, требования которого были: 1. Что бы у всех пользователей было заполнено поле mail 2. Новый пользователь vmail (пароль скажут после установки пакета iRedmail) 3. Поле для квоты. Также обсуждался безопасный тунель между сервером почты и сервером OpenLDAP. Найденный подрайдчик считал, что лучшее решение -- это использование VPN, чтобы и OpenLDAP, и Dovecot виртуально были бы в одной сети. Авторизация почтового сервера идёт через Dovecot. Другой специалист называл такое решение идиотским. После решения о переходе с OpenLDAP на WSO2 IS подрячиков не искали.
2. Задокументировать решения и настройки.

Резервное копирование===

В Облаке, к резервному копированию применяется несколько подходов. Копируются приложения и сервера; сохраняются базы и делаются снимки.

• Изначально использовался rsync для копирования файлов, еженедельно полный бэкап и ежедневно incremental бэкап заливались на backup space на Contabo. Была идея использовать rsnapshot для снимков, но эту идею пока не получилось реализовать.
• Весной-летом 2021 года, начались эксперименты с Veeam Agent for Linux, для которого был установлен VNC® Viewer. Это обеспечение позволило копировать полный сервер.

Надо создать:

1. Подробное описание существующей системы.
2. Процедуру проверки надёжности бэкапов.

Приложенческие проекты

В существующую технологию включено много пользовательских приложений, упомянутых выше. Для всех, надо:

1. Обновлять все приложения до последних стабильных версий и устанавливать свежие патчи, когда они появляются в наличии. Основное требование для любого приложения -- привязка к нашему WSO2 Identity Server (WSO2 IS). Дополнительное требование для любого приложения -- привязка к нашему OpenLDAP.
2. Документировать то, что у нас есть, и выявлять проблемы.

Приоритетные проекты:

1. Перевод Оплёта на WSO2 IS
2. Устойчивость для Жици. Наиболее критическое приложение -- Брацки Жици на Jitsi. Эта видео-конференционная система пока установлена вместе с пользовательскими системами. Возможно, для него должен быть построен отдельный кластер, задействующий все имеющиеся в наличии сервера. Также обсуждается план увести её отдельно на CDN типа Cloudflare или глобальные облачные решения -- Microsoft Azure или AWS -- участники конференций могут находиться на разных континентах и требование к качеству особо высокое.

Дополнительные проекты:

1. LDAP для Правки
2. CDN для Оплёта
3. Перевод Крынки на GitLab

Профинансированные проекты приложений

Работы	Бачка	Вебка	Жици	Крынка	Пошта	Правка	Связка	Сетка	Справа	Учебка
Запрос	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно
Требования
Архитектура
Модель
Прототип
Заказ
Производство	Наработки	Наработки	Наработки		Наработки	Наработки			Наработки
Конфигурация
Усовершенствование

Федерационные проекты

Надо:

1. Добиться изменения ролей по завершению курсов Учебки. Данные о завершении определённых курсов Учебки должны отдаваться в Оплёт, тот должен назначать новую роль в зависимости от завершённых курсов и отдавать сведения в WSO2 IS.
2. Подготовиться к смене морды, когда её новый дизайн будет готов,
3. Настроить восстановление пароля,
4. Добавить CAPTCHA на регистрацию -- ранее была установлена Google-овская ReCAPTCHA, однако она не работала для пользователей в Китае, где услуги Google заблокированы, и потому была отключена.
5. Унифицировать тесты по всей платформе.
6. В Учебке (Moodle) активно используется элемент "Лекция", но не похоже, что этот элемент не сохраняет ответы учеников. Например, элемент "Тест" сохраняет абсолютно все ответы. Однако некоторые из ответов в лекциях необходимы для сохранения в качестве полей профиля. Мудл содержит пару плагинов для лекций, но не ясно решают ли эти плагины проблему сохранения ответов. Если существующие плагины не могут решить проблему, необходимо модернизировать родной плагин.

Федерационная идентификация===

Пользовательская федерация налаживается на базе WSO2 Identity Server. До лета 2021, она строилась на OpenLDAP, а до 2018 года -- на SimpleSAMLphp.

1. Перевести основную идентификацию и авторизацию с OpenLDAP на WSO2 Identity Server в рамках проекта Перевод Оплёта на WSO2 IS.
2. В тех приложениях, которые работают с OpenLDAP, на регистрационных страницах оставить кнопку "LDAP login". Альтернативно, эту кнопку можно разместить на регистрационной странице WSO2 IS.
3. Разрешить проблему ролей. По окончании курса Учебка (Moodle) должна отдавать информацию Оплёту, тот должен назначать новую роль и отдавать эту роль в WSO2 Identity Server, а WSO2 Identity Server -- распространять по всем приложениям. Ранее эту проблему пытались решать с OpenLDAP. Всё решалось пока не сломались на проблеме изменения ролей -- OpenLDAP принимал только одну роль и далее не менял её.
4. Проверка SSO. Более 3х десятков пользовательских приложений включено в "Облако" и, заходя в каждое из них, сейчас пользователь не должен логиниться отдельно. Теоретически, SSO -- это родная функция WSO2 Identity Server, но, после перехода с OpenLDAP на WSO2 Identity Server, каждое приложение должно проверяться.

Профинансированные проекты Оплёта

Работы	Календарь	Каптча	Курсы	Роли	Тесты
Запрос	Достаточно	Достаточно	Достаточно	Достаточно	Достаточно
Требования
Архитектура
Модель
Прототип
Заказ
Производство	Наработки
Конфигурация
Усовершенствование

Кроме того, сам Оплёт должен быть переделан в кластер.