Centos 7

Из песочницы Миграция Jira Service Desk из облака на сервер

15.11.2020 18:09:06 |

Автор: admin

Не буду спорить, что использование SaaS-ов, и в частности Jira Service Desk Cloud, удобно и облегчает работу системным администраторам. В целях безопасности или более гибкого управления сервисом, которое не предоставляет облако, может потребоваться перенос сервиса из облака на сервер организации.

Процесс миграции Jira Service Desk(JSD) можно условно разделить на три этапа:

Подготовка резервной копии(бэкапа).
Подготовка сервера. Установка программного обеспечения. Настройка.
Развертывание бэкапа из облака на сервере.

К подготовке сервера можно отнести установку операционной системы на сервер, установку программного обеспечения, настройку. Сервер может быть как физическим, так и виртуальным. В моем случае будет использоваться CentOS 7, а программное обеспечение будет автоматически устанавливаться простым скриптом. Установка CentOS 7 описана не будет. Будем считать, что ОС уже установлена.

Технические требования к серверу можно посмотреть по ссылке.

1) Подготовка резервной копии.

Сделаем бэкап нашего облачного JSD.

Заходим в системные настройки облачного JSD, вкладка Управление резервным копированием.

Сделаем резервную копию сервера.

Выбираем полную миграцию сервера и загружаем резервную копию. На резервное копирование есть ограничение в 48 часов. То есть, после создания бэкапа, следующий можно будет сделать только через 2 дня.

2) Подготовка сервера. Установка программного обеспечения. Настройка.

Скрипт можно скачать тут любым удобным для вас способом.

Запускаем терминал или подключаемся к серверу по SSH.

Добавим права на выполнение скрипту командой:

sudo chmod +x soft_install_c7.sh

Запускаем скрипт командой:

sudo bash soft_install_c7.sh

Начнется обновление и затем установка программного обеспечения.

Кроме установки ПО скрипт создаст базу данных(БД) в Postgre Sql

При создании БД скрипт может ругнуться на доступ. Ничего страшного, база будет создана.

После завершения исполнения скрипта можно зайти в консоль Postgre Sql и убедится в этом.

В процессе исполнение скрипта необходимо будет ввести e-mail и пароль для настройки pgAdmin 4 и ответить на несколько вопросов.

Бинарный файл для установки JSD скачается и запустится автоматически. Необходимо будет ответить на несколько вопросов.

Порты для работы JSD можно оставить по умолчанию или выбрать другие.

Правила брандмауэра для корректной работы Apache, pgAdmin 4 и JSD добавятся автоматически. По умолчанию скрипт откроет порты 80, 8080 и 5432.

Добавить порт по своему усмотрению можно командой:

sudo firewall-cmd --zone=public add-port=порт/tcp permanent

Удалить порт можно командой:

sudo firewall-cmd --zone=public --remove-port=порт/tcp --permanent

Посмотреть все правила брандмауэра можно командой:

sudo firewall-cmd list-all или sudo iptables -L -n -v line-numbers

Для перезагрузки брандмауэра используйте команду:

sudo firewall-cmd --reload

Исполнение скрипта завершится сообщением DONE!

В завершении подготовки сервера можно подключить pgAdmin 4 к серверу Postgre Sql через адрес локальной петли 127.0.0.1, или как вам больше нравится. Измените настройки в pg_hba.conf на актуальные для вашей конфигурации, если это необходимо.

Логин и пароль для базы можно посмотреть в скрипте:

База: jsd_db
Пользователи:
Логин:jira Пароль:123
Логин:postgres Пароль:postgres

Можете изменить на свои значения перед запуском скрипта или после, непосредственно в Postgre Sql.

Не забудьте отключить SSL, если вы его не используете. Если pgAdmin 4 не будет соединяться с сервером, попробуйте перезагрузить службу.

sudo service postgresql-11 restart

Информацию по базам данных вы можете найти в документации Atlassian.

3) Развертывание бэкапа из облака на сервере.

В браузере переходим по ip-адресу сервера с указанием порта. По умолчанию порт 8080. У меня это выглядит так 192.168.1.25:8080

Вы должны увидеть следующее.

Я выбираю пункт выполнить настройку самостоятельно и на следующей странице указываю настройки для базы данных. После подключение начнется создание базы данных это займет некоторое время.

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

Выбираем импортировать данные.

В полях открывшейся страницы указываем наименование бэкапа, лицензию(если необходимо) и настройки почты.

Можно сгенерировать триальную лицензию на месяц на сайте Atlassian. Для этого нужно будет зарегистрироваться на сайте. При генерации лицензии необходимо выбрать jira service desk (server).

Перед восстановлением JSD из бэкапа разместите бэкап на сервере в каталоге /var/atlassian/application-data/jira/import

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

Вас приветствует страница входа, если все прошло хорошо. Осталось ввести логин и пароль.

По умолчанию логин sysadmin, пароль sysadmin.

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

На этом перенос JSD из облака на сервер закончен.

Еще почитать о миграции можно тут.

Спасибо за внимание, всего хорошего и удачи!

Подробнее..

Категории: Backup , Linux , Настройка linux , Софт , Cloud , Bash , Atlassian , Centos 7 , Server , Jira service desk

Из песочницы Доверяй, но проверяй контроль неотправленных писем в Битриксе с уведомлением админу

09.07.2020 20:08:37 |

Автор: admin

Предыстория

Когда-то у меня возникла необходимость проверять наличие неотправленных сообщений в 1С-Битрикс: Управление сайтом (далее Битрикс) и получать уведомления об этом. Проблемы с отправкой почты были крайне редкими, однако довольно неприятными событиями, т.к. обычно это были заказы, подтверждения регистрации и прочие важные письма.

Сложность была в том, что если используемый Битриксом метод отправки почты перестал работать(с большой вероятностью причина в этом), то этим же самым методом отправлять уведомление будет ненадёжно.

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

Задача

Получить реквизиты для соединения с БД из конфига сайта Битрикса
Соединиться с БД
Проверить количество неотправленных писем
Сравнить количество с предельно допустимым
Принять решение об отправке уведомления

Реализация

На вход shell-скрипту будут поступать 3 параметра:

Путь к конфигу сайта Битрикса (path_to_bxdb_config)
Текст запроса к БД (single_num_value_query)
Предельно допустимая величина (max_num_value)

Для корректной работы запрос к БД должен возвращать одиночное числовое значение.

Код скрипта check_bx_db_value.sh

#!/bin/bash## Site: https://github.com/AlexeyGogolev/check-bx-db-value#mysql="$(which mysql)" # получение пути к mysqlphp="$(which php)" # получение пути к phpdeclare -A CLParams # массив значений параметров КСdeclare -a CLParams_keys # массив ключей для массива параметров КСdeclare -A DBSettings # массив значений переменных конфигаdeclare -a DBSettings_keys # массив ключей для массива значений переменных конфигаDBSettings_keys=(DBLogin DBPassword DBName)CLParams_keys=(path_to_bxdb_config single_num_value_query max_num_value)param_num=0 # счетчик параметров КС# получение параметров КСfor key in "${CLParams_keys[@]}" ; do     ((param_num++))                     CLParams[$key]=${!param_num}    # ${!param_num} здесь генери-т $1 $2... done# если нет последнего параметра, показываем справкуif  [ -z "${CLParams[${CLParams_keys[$param_num-1]}]}" ] ; then    printf "Script compares result returned by <${CLParams_keys[1]}> to given <${CLParams_keys[2]}>.\nIf the result more than the given value, then exit with code 1, else exit 0.\n"    printf "Usage: \n\t$(basename ${BASH_SOURCE[0]}) " ; for key in "${CLParams_keys[@]}" ; do printf "<$key> "; done ; printf "\n"    printf "Example: \n\t$(basename ${BASH_SOURCE[0]}) \"/www/ab.cd/bitrix/php_interface/dbconn.php\" \"select count(id) from b_event where SUCCESS_EXEC<>'Y'\" 5\n"     exit 10fi# выход если конфиг пустой или его нет if ! [ -s "${CLParams[path_to_bxdb_config]}" ] ; then     printf "File ${CLParams[path_to_bxdb_config]} doesn't exist or empty.\n"    exit 20fi# выход если параметр запроса к БД содержит команду из "запретного списка"echo ${CLParams[single_num_value_query]} | grep -i -q -E 'delete|update|insert|drop' && printf "query \n${CLParams[single_num_value_query]}\nisn't allowed\n" && exit 30# получение значений переменных из php-config -n -- без php.ini , -r -- выполнить код без тэгов <?...?>for key in "${DBSettings_keys[@]}" ; do     DBSettings[$key]="$($php -n -r 'include("'${CLParams[path_to_bxdb_config]}'"); print $'$key';')"done# экспорт пароля mysql в переменную окружения (по соображениям безопасности)export MYSQL_PWD=${DBSettings[DBPassword]}# получение одиночного значения из БД: -N -- без названий колонок ; -B - (batch) - результаты без "бокса" вокруг значений; -e выполнить запросnum_value=`${mysql} -u ${DBSettings[DBLogin]} -N -B -e "use ${DBSettings[DBName]}; ${CLParams[single_num_value_query]}"`# отображение значенийecho "Result of the query (from DB ${DBSettings[DBName]}): ${num_value}, ${CLParams_keys[2]}: ${CLParams[max_num_value]}"# сравнение значенийif [ $num_value -gt ${CLParams[max_num_value]} ]; then    exit 1fi

Пример вызова скрипта

#!/bin/bashcheck_bx_db_value.sh \/www/ab.cd/bitrix/php_interface/dbconn.php \select count(id) from b_event where SUCCESS_EXEC<>'Y' \2

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

запускаем:

$ ./ab_cd_unsent_check.sh && echo "success" || echo "failure"

получаем:

Result of the query (from DB ab_cd): 0, max_num_value: 2success

Добавим неотправленных сообщений и запустим снова.

$ ./ab_cd_unsent_check.sh && echo "success" || echo "failure"

а теперь:

Result of the query (from DB ab_cd): 4, max_num_value: 2failure

Все работает как нужно! В первом случае значение в БД не превышает заданного, скрипт выдает код 0 по завершении. Во втором значение в БД превышает заданное, скрипт завершается с кодом ошибки.

Настройка конфигурации monit

В данной статье я приведу пример конфигурации monit для отправки сообщений на e-mail.
Подразумевается, что на машине уже установлен и настроен monit.

Для повышения надёжности, в конфиге monitrc следует указывать аккаунт на почтовом сервере, отличном от используемого Битриксом для отправки писем. Кроме того, путем настройки и запуска дополнительных скриптов в конфигурации monit можно выполнять отправку сообщений в мессенджеры и соцсети.

Пример конфигурации monit

check program ab_cd_unsent_check with path /home/bitrix/scripts/ab_cd_unsent_check.shevery 2 cycles    group mailif status != 0 then alert

Файл конфигурации следует поместить в /etc/monit.d/.

Для упрощения демонстрации, в этом примере установлено 2 цикла (здесь 1 цикл = 30 сек).
Чтобы monit не отправлял ложные алерты, в реальных условиях, нужно ставить столько циклов, чтобы письма успевали уходить подбирается опытным путём. Здесь следует учитывать среднее количество сообщений, генерируемых сайтом, и скорость(время) их обработки почтовым сервером.

Для проверки работы конфигурации в терминале выполняем:

# systemctl restart monit# monit status

получаем:

Без неотправленных сообщений

С неотправленными сообщениями

Так выглядят уведомления от monit на почту:

Появились неотправленные сообщения!

Все сообщения отправлены (теперь всё норм.).

Отправка уведомлений из monit работает корректно.

Заключение

Надеюсь решение получилось достаточно универсальным и подойдёт для других задач.

Вот и всё! Исходники для статьи можно скачать здесь.

P.S. Кому не сложно прошу поделиться в комментариях возникают ли у вас подобные задачи?
Если да, то каким образом они решаются?