СИСТЕМА ПЕРЕДАЧИ ИЗВЕЩЕНИЙ “ЮПИТЕР”

Программное обеспечение БД Юпитер Firebird

версия 4.7

Руководство администратора

(ред.2.7)

Санкт-Петербург

2014

ООО «Элеста» СПИ «Юпитер»

Оглавление

1. Установка Редактора БД Юпитер

1.1. Состав дистрибутива

1.2. Предварительные условия

1.3. Результат инсталляции

1.4. Запуск приложений на рабочих местах пользователей

1.5. Деинсталляция ПО

2. Управление пользователями

2.1. Группы пользователей

2.2. Уровни доступа к Редактору БД Юпитер

2.3. Порядок создания пользователей

2.4. Смена паролей пользователей

2.5. Смена пароля пользователя «SYSDBA»

2.6. Проверка прав пользователя Редактора БД при соединении

2.7. Удаление (запрещение) пользователей

2.7.1. Пользователи Редактора

2.7.2. Пользователи Пульта

3. Меню «Сервис»

3.1. Глобальные справочники

3.2. Глобальные настройки

4. Резервное копирование и восстановление

4.1. Общая схема резервного копирования

4.2. Функции серверов

4.3. Алгоритмы

4.4. Настройка штатной конфигурации

4.5. Действия в случае сбоя Главного сервера

4.5.1. Переключение на Резервный сервер

4.5.2. Обратное переключение на Главный сервер

4.6. Где искать "следы" резервного копирования

4.7. Обработка критических ситуаций

4.8. Создание и восстановление резервных копий «вручную»

5. Ключи приложений

2 ПО БД «Юпитер». Руководство администратора ООО «Элеста» СПИ «Юпитер»

Это руководство предназначено для тех сотрудников, которые по роду своих обязанностей выполняют следующие задачи:

• устанавливают системное и прикладное ПО;

• отвечают за конфиденциальность данных;

• конфигурируют серверы баз данных и занимаются резервным копированием и восстановлением данных.

1. Установка Редактора БД Юпитер Пожалуйста, ознакомьтесь внимательно с содержанием данной главы, прежде чем приступать к процессу установки (инсталляции). Поскольку в процессе инсталляции может создаваться база данных, могут изменяться структуры данных и сами данные, настоятельно рекомендуем сделать резервные копии всех баз данных, если таковые используются в настоящий момент.

Также рекомендуем выбрать время для инсталляции, когда сервер СУБД FireBird не используется в работе критически важных приложений.

Рекомендуем использовать для БД Юпитер выделенный сервер FireBird, который обслуживает только БД Юпитер.

При возникновении неразрешимых проблем, пожалуйста, обращайтесь в службу поддержки ООО "Элеста". Возможно, нам потребуется протокол инсталляции "install.log", который должен сформироваться в Папке установки.

1.1. Состав дистрибутива В дистрибутив Редактора БД Юпитер (далее ПО) входят:

• Скрипты для создания базы данных • Исполняемые файлы • Файлы документации • Конвертеры из баз предыдущих форматов 1.2. Предварительные условия Предполагается, что ПО устанавливается на сервер, на котором уже установлен и запущен сервер СУБД FireBird версии 2.1.4. Установки, предлагаемые FireBird по умолчанию, вполне подходят для работы ПО.

Сервер FireBird выполняется как служба с именем "FireBirdServerDefaultInstance" и принимает запросы с локального хоста. Для обслуживания запросов с других хостов необходимо открыть порт TCP 3050.

Внимание. ПО может работать с нестандартно настроенным сервером FireBird – если он работает не как служба и (или) настроен на нестандартный порт, - но в этом случае Вы должны ясно представлять, что Вы делаете. При необходимости нестандартной конфигурации, пожалуйста, проконсультируйтесь в службе поддержки ООО «Элеста».

В процессе инсталляции служба сервера FireBird может быть перезапущена. Поэтому выберите для инсталляции время, когда это можно сделать, не нарушая нормальную работу пользователей.

Известны имя и пароль суперпользователя FireBird. От его имени будет выполняться создание базы данных. По умолчанию - это пользователь "SYSDBA" с паролем "masterkey".

Инсталлятор в процессе работы использует утилиту "isql" из состава FireBird и изменяет конфигурационный файл FireBird "aliases.conf". Чтобы найти их, надо знать каталог, в котором установлен FireBird. Инсталлятор предполагает, что каталог установки хранится в имени "DefaultInstance" ключа "HKLM\Software\FireBird Project\FireBird Server\Instances\" реестра Windows. Если FireBird установлен в другой каталог, Вам потребуется указать его в ПО БД «Юпитер». Руководство администратора ООО «Элеста» СПИ «Юпитер»

процессе инсталляции.

1.3. Результат инсталляции Будем считать, что в процессе инсталляции задано имя базы данных "Jupiter-4" и папка установки "C:\JupDB\4".

Если процесс инсталляции завершился успешно, то будет выполнено следующее:

1. Если создаётся новая база данных, то она будет создана в файле "C:\JupDB\4\fdb\Jupiter-4.fdb".

2. Этой базе данных присвоен псевдоним "Jupiter-4", так что к ней можно подсоединяться локально как к "localhost:Jupiter-4" или, с удалённых рабочих мест, как к “:Jupiter-4”.

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

4. Если была задана загрузка тестовых данных или загрузка из существующей базы, то эти данные загружены в базу.

5. Созданы каталоги и файлы в них:

\bin - исполняемые файлы, библиотеки, файлы конфигураций install.log - протокол инсталляции ВНИМАНИЕ. Не рекомендуем изменять структуру Папки установки, а также перемещать, переименовывать или удалять файлы внутри неё. В противном случае нормальную работу ПО Юпитер гарантировать нельзя. Это особенно важно для резервного копирования.

1.4. Запуск приложений на рабочих местах пользователей Приложения ПО находятся в каталоге "C:\JupDB\4\bin":

• JupAdmin.exe – Администратор БД Юпитер • остальные приложения предназначены для запуска только на сервере, но не рабочих местах пользователей.

Приложения можно запускать двумя основными способами.

1. Их можно запускать на любом удалённом компьютере, которому разрешено чтение каталога "C:\JupDB\4\bin".

2. Использовать механизм запуска ENLP, описанный в документе «ENLP. Руководство пользователя».

Ни в первом, ни во втором случае специальной инсталляции на рабочие места пользователей не требуется.

На некоторых рабочих местах может понадобиться установка дополнительного ПО (vcredist_x86.exe). В этом случае приложение запросит у пользователя подтверждение на установку и запустит её. Для каждого рабочего места это делается однократно.

1.5. Деинсталляция ПО В процессе инсталляции не производится запись в системный реестр Windows. Деинсталляция сводится к удалению файлов из каталога (и самого каталога) "C:\JupDB" и может быть произведена "вручную".

2. Управление пользователями 2.1. Группы пользователей Пользователи ПО Юпитер делятся на две группы:

1. Пользователи Редактора.

2. Пользователи Пульта.

Эти группы не пересекаются. То есть, если необходимо дать одному и тому же сотруднику и доступ к Редактору, и доступ к Пульту, придётся создать двух разных пользователей.

2.2. Уровни доступа к Редактору БД Юпитер Пользователи Редактора делятся по уровню доступа на 5 категорий:

1. Не имеющие никаких прав – роль в БД RL_NONE.

2. Имеющие права только на чтение данных – RL_READER.

3. Имеющие права на чтение и изменение данных – RL_WRITER.

4. Имеющие права администратора — RL_ADMIN, могут всё, что RL_WRITER плюс имеют право выполнять приложение JupAdmin.exe.

5. Суперпользователь FireBird SYSDBA – при любых условиях имеет право выполнять приложение JupAdmin.exe.

2.3. Порядок создания пользователей Создание пользователей и раздача им прав должна происходить в следующем порядке:

1. SYSDBA с помощью программы JupAdmin создаёт одного (или нескольких) пользователей Редактора с правами RL_ADMIN.

2. Пользователь, имеющий права администратора, с помощью программы JupAdmin создаёт пользователей Редактора с правами RL_READER, RL_WRITER, RL_NONE, а также пользователей Пульта.

При инсталляции создаются два пользователя Редактора:

• Пользователь OVO с правами RL_READER (его имя и пароль можно изменить в процессе установки). Это «стандартный» пользователь для просмотра данных.

Пользователь PULT с правами RL_WRITER. Это специальный пользователь, от имени которого соединяются все приложения АРМ ДО (ДПЦО) и АРМ ДПУ. Его имя менять не рекомендуется.

2.4. Смена паролей пользователей При смене пароля любого пользователя (кроме SYSDBA) средствами программы JupAdmin пароль изменяется и в базе безопасности FireBird, так что никаких дополнительных действий не требуется.

2.5. Смена пароля пользователя «SYSDBA»

Пароль пользоваетеля «SYSDBA» сначала измените штатными средствами FireBird, например, утилитой gsec.

Затем запустите программу JupAdmin от имени SYSDBA, используя новый пароль, и выполите пункт меню Пользователи::Смена пароля SYSDBA.

2.6. Проверка прав пользователя Редактора БД при соединении Когда пользователь соединяется с БД, сначала проверяется его имя и пароль на уровне FireBird.

Если такой пользователь в FireBird существует, то считывается его роль (RL_NONE, RL_READER, RL_WRITER, RL_ADMIN) и осуществляется повторное соединение уже с указанием этой роли.

Для поддержки такой двухшаговой проверки нужно, чтобы пользователи в FireBird (в его собственной базе безопасности) имели такие же имена, которые им даны в JupAdmin. Конфигурация пользователей в FireBird происходит автоматически в процессе создания (изменения) пользователей в программе JupAdmin. При этом достигаются 2 цели:

1. Пользователи получают роли на уровне FireBird, что ограничивает их права, даже если они попытаются соединиться с БД при помощи других приложений (isql, 2. Сотрудник, выполняющий роль администратора баз данных, освобождается от необходимости конфигурировать пользователей. Он должен выполнить только п.1 из 2.7. Удаление (запрещение) пользователей Удаление пользователей из системы различается в зависимости от их типа: пользователи редактора БД и пользователи пульта.

2.7.1. Пользователи Редактора Однажды созданный пользователь Редактора БД никогда не удаляется из БД Юпитер.

Для временного запрещения входа в Редактор можно ограничить уровень пользователя до "Нет доступа" (RL_NONE).

Для постоянного запрещения входа (например, при увольнении) надо в JupAdmin выполнить Пользователи Редактора (или Пульта) Пользователь Запретить.

2.7.2. Пользователи Пульта Пользователи Пульта при удалении действительно удаляются из БД.

3. Меню «Сервис»

В меню «Сервис» доступны следующие функции:

3.1. Глобальные справочники JupAdmin позволяет редактировать глобальные справочники:

• Пароли ручных ключей. Пароли взятия/снятия для ключей, охраняемых по «ручной»

тактике. Используются ПО АРМ ДПУ и могут генерироваться «вперёд» на несколько месяцев (лет).

Основные примечания (пульт). Стандартные примечания, которые используют дежурные в АРМ ДПУ, чтобы не набирать их каждый раз заново.

ДО. Распределённая передача тревог. Задаёт список компьютеров АРМ ДО (ДПЦО), на которые может осуществляться передача тревог из АРМ ДПУ.

Причины тревог. Стандартные причины тревог, которые используют дежурные в АРМ ДПУ и в АРМ ДО, чтобы не набирать их каждый раз заново.

Шаблоны SMS-оповещений. Наборы (шаблоны) сигналов СПИ, для которых требуется отсылать SMS-оповещения.

3.2. Глобальные настройки Редактор БД Юпитер — приложение JupDB.exe, — использует некоторые настройки, которые действуют на всех пользователей и поэтому называются глобальными.

Смысл настроек объясняется в комментариях при редактировании.

ВНИМАНИЕ. Настройки вступают в действие только при перезапуске приложений JupDB.exe.

4. Резервное копирование и восстановление Для обеспечения сохранности информации, хранящейся в БД, в случае возникновения программных или аппаратных сбоев необходимо настроить систему резервного копирования.

4.1. Общая схема резервного копирования Есть 3 вида серверов, на которых работает Firebird и установлено ПО Редактор БД:

Резервный (Backup) Достаточно одного, но может быть и несколько.

Вторичный (Slave) Может быть несколько.

В схеме резервного копирования предполагается, что структура каталогов осталась такой, как была создана при установке, а именно:

fbk – файлы резервных копий и протоколов копирования.

Также предполагается, что FireBird выполняется как служба, а не как приложение.

Если Вы использовали установки по умолчанию, то эти условия соблюдаются.

4.2. Функции серверов.

Главный К нему подключен АРМ ДПУ в режиме «Сервер».

В его БД пользователи Редактора ведут базу карточек.

Резервный • Представляет собой горячий резерв на случай выхода из строя Главного.

• Осуществляет периодическое резервное копирование БД с Главного.

• Выкладывает последнюю версию БД для Вторичных серверов.

Функции Главного и Резервного сервера могут совмещаться одним компьютером.

Вторичный Служит автономным сервером для АРМ ДПУ и АРМ ДО, если их невозможно подключить напрямую к Главному.

Периодически проверяет наличие свежей версии БД и переходит на работу с ней.

4.3. Алгоритмы Администратор настраивает периодическое выполнение задачи JupBackup.exe • либо используя службу "Планировщик заданий" (http://www.windowsfaq.ru/content/view/338/19/1/1/) • либо в приложении JupAdmin.exe.

Если администратор настраивает и то, и другое, ответственность за возможное некорректное выполнение резервного копирования лежит на нём.

Главный Никаких действий, связанных с резервным копированием, не делает. Настройки периодического выполнения не требуются.

Резервный • Выполняет периодическое резервное копирование БД с Главного.

• Сохраняет полученную копию с именем YYYY-MM-DD-HH-MM-SS.fbk.

• Выполняет восстановление этой копии в БД YYYY-MM-DD-HH-MM-SS.fdb.

• Повторяет процесс резервирования/восстановления, пока восстановление не будет успешным. Число попыток настраивается.

• Удаляет старые резервные копии, оставляя только копии за задаваемый промежуток • Если сервер не является Главным, то удаляет существующий jupiter-4.fdb и создаёт новый jupiter-4.fdb из YYYY-MM-DD-HH-MM-SS.fdb. Это действие требует остановки и запуска службы FireBird.

• Выкладывает YYYY-MM-DD-HH-MM-SS.fbk для Вторичных серверов.

Вторичный • Периодически проверяет наличие свежей резервной копии БД в каталоге fbk.

• Восстанавливает копию в fdb (аналогично Резервному серверу) и переходит на работу с новой БД.

• Если восстановление завершается с ошибкой, то просто продолжает работать на прежней БД.

• Свежими считаются копии, которые отстоят назад на число дней меньшее, чем указано в параметре «Резервные копии и log- файлы хранить дней» настроек резервного копирования. Восстанавливается одна — самая последняя — из них.

4.4. Настройка штатной конфигурации.

На Главном сервере в JupAdmin • установите роль сервера "Главный".

На Резервном сервере • установите роль сервера "Резервный";

• настройте параметры соединения с Главным сервером;

• настройте расписание резервного копирования в JupAdmin или в планировщике заданий - (Панель управления -> Назначенные задания);

• если существуют Вторичные серверы, то настройте каталоги для них.

На Вторичном сервере(ах) • установите роль сервера "Вторичный";

• настройте расписание резервного копирования в JupAdmin или в планировщике заданий - (Панель управления -> Назначенные задания).

Если Вы планируете запуск «С интервалом», то выберите интервал достаточно большим, чтобы процедуры резервного копирования и восстановления успевали выполниться за это время.

В противном случае Вы будете постоянно получать сообщения о попытках повторного запуска в файле fbk\errors.log (см. ниже).

4.5. Действия в случае сбоя Главного сервера.

4.5.1. Переключение на Резервный сервер 1. На Резервном сервере установите роль "Главный + Резервный". В этом режиме сервер выполняет резервное копирование с самого себя.

2. Запустите на этом сервере JupAdmin.exe и выполните операцию Пользователи -> Смена пароля SYSDBA. При этом пользователи из базы данных будут перенесены в Firebird на этом сервере. В качестве старого пароля SYSDBA необходимо использовать пароль, который имел SYSDBA на Главном сервере.

3. Переключите пользователей на работу с этим сервером. То есть, пользователи должны перезапустить приложения JupDB.exe, указав параметры соединения с Резервным 4.5.2. Обратное переключение на Главный сервер.

1. На Главном сервере в приложении JupAdmin.exe установите роль "Резервный".

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

4. Из меню Сервис посмотрите файлы протоколов и удостоверьтесь, что резервное копирование прошло успешно.

5. Установите роль "Главный".

6. Выполните операцию Пользователи -> Смена пароля SYSDBA. При этом пользователи из базы данных будут перенесены в Firebird на этом сервере. В качестве старого пароля SYSDBA необходимо использовать пароль, который имел SYSDBA на Резервном сервере.

7. Переключите пользователей на работу с этим сервером. То есть, пользователи должны перезапустить приложения JupDB.exe, указав параметры соединения с Главным 8. На Резервном сервере установите роль "Резервный".

4.6. Где искать "следы" резервного копирования.

Если резервное копирование не выполняется вообще или выполняется с ошибками, то разбирать ситуацию надо в следующем порядке.

1. Посмотрите, создался ли файл журнала (протокол) за интересующий день в каталоге fbk. Файл имеет имя вида 2009-12-31.log. Если файл есть и есть записи за интересующее время, то это наиболее полная информация о попытках резервного копирования. Файлы протоколов можно просматривать в JupAdmin.

2. Если файла журнала за интересующий день нет, или в нём нет записей за интересующее время, возможно, приложение JupBackup.exe не смогло отработать.

Посмотрите в системных событиях (Панель управления Администрирование Просмотр событий) есть ли записи с Источником JupBackup в ветке ( Приложение).

В нормальной ситуации JupBackup пишет 2 уведомления: одно с текстом, который заканчивается словами "Запуск приложения.", другое «Нормальное завершение.»

В случае серьёзных ошибок JupBackup пишет сообщения об ошибках, которые он смог отследить.

3. Если в системных событиях записей с источником JupBackup нет, то служба запуска заданий по расписанию:

либо не смогла запустить JupBackup.exe, тогда там же, в просмотре событий в ветке ( Система) поищите события за интересующее время с Источником Если есть сообщения об ошибках с примерно таким текстом:

«Сбой при запуске команды At1.job из-за ошибки Не удается найти указанный файл.», то это либо ошибка в приложении JupBackup (если расписание настраивалосьв JupAdmin), либо неверно настроены задания в Панель управления Назначенные задания (если расписание настраивалось там).

4.7. Обработка критических ситуаций 1. Файл fbk\errors.log используется как индикатор ошибок, возникших в процессе резервного копирования.

• Создаётся приложением JupBackup • Удалять должен человек - системный администратор 2. Если файл есть, то это сигнал для администратора о том, что надо предпринимать действия по исправлению ошибок. После устранения ошибок администратор должен удалить файл.

3. Файл создаётся и в него записываются:

• Обычные ошибки, те, которые записываются в log-файлы с • Ошибки, которые записываются в системный журнал.

4. Может случиться так, что утилита резервного копирования gbak остановится и будет ждать ввода пользователя. Тогда запускать второй процесс JupBackup не имеет смысла. Вообще любая попытка запустить второй процесс резервного копирования при ещё не завершившемся первом, считается критической ошибкой и записывается в fbk\errors.log.

4.8. Создание и восстановление резервных копий «вручную»

Только для опытных пользователей.

Убедитесь, что Вы понимаете цель своих действий и назначение команд, которые используете.

Если Вы не хотите по каким-либо причинам настраивать резервное копирование так, как здесь описано, пользуйтесь стандартной утилитой резервного копирования gbak из дистрибутива Firebird.

См. официальную документацию:

http://www.firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/gbak.ht JupBackup использует для резервного копирования команду вида:

"c:\Program Files\Firebird\Firebird_2_1\bin\gbak.exe" -B -USER SYSDBA -PASSWORD masterkey localhost:jupiter-4 "c:\JupDB\4\fbk\2014-02-20-16-29-58.fbk" Для восстановления используется команда вида:

"c:\Program Files\Firebird\Firebird_2_1\bin\gbak.exe" -USER SYSDBA -PASSWORD masterkey -c "c:\JupDB\4\fbk\2014-02-20-16-29-58.fbk" localhost:"c:\JupDB\4\fdb\2014-02-20fdb" Звтем нужно остановить службу Firebird, переименовать 2014-02-20-16-29-58.fdb в jupiter-4.fdb и снова запустить службу.

5. Ключи приложений Приложения JupDB и JupAdmin можно запускать с ключами. Это может пригодиться для «автоматического» соединения с БД без окна Аутентификации, если указать в командной строке все параметры соединения с БД — сервер, псевдоним БД, пользователя и пароль.

• -s Сервер Имя или IP-адрес сервера, на котором находится БД. Если на указанном сервере FireBird настроен на нестандартный порт, то его надо указать здесь через прямой слэш (косая черта), например, 192.168.208.1/30501.

Псевдоним БД, например, jupiter-4.

Имя пользователя, как оно было задано в программе Администратор БД, например, Maria. Регистр букв (большие, малые) имеет значение.

Пароль пользователя, как он был задан в программе Администратор БД, например, J,b.F. Регистр букв (большие, малые) имеет значение.

Debug{File, Memo, meSsage}, уровень отладочных сообщений, которые должны сохраняться в Файле журнала, выводиться в Memo-поля или выводиться в виде окон Сообщений. Error, Warning, Notice, Debug. Каждый следующий уровень включает предыдущий. Например, по умолчанию задано:

-df n. В журнал выводятся сообщения уровня Error, Warning, Notice.

-dm w. В Memo-поля выводятся сообщения уровня Error, Warning.

-ds e. В окна сообщений выводятся только сообщения уровня Error.

В уровне Debug выводится довольно много сообщений, поэтому пользоваться этим уровнем имеет смысл только для вывода в Файл журнала.