Get Social

Как поменять сопоставление Mysql базы для Jira на сервере Ubuntu + Plesk

Как поменять кодировку Mysql базы для Jira на сервере Ubuntu + Plesk картинка

The Collation health check has failed in your system

Такое сообщение выдала Jira, спустя какое-то время после установки. Это было из-за того, что база и пользователь были созданы штатными средствами панели Plesk (то же самое получилось бы и во многих других случаях), и база данных с таблицами в ней получили сопоставление, которое использовалось в Mysql по-умолчанию: “utf8_general_ci”.

Уже были созданы пользователи, задачи и работа шла полных ходом. При этом каких-то проблем в работе не было, однако, согласно этому источнику, лучше исправить эту ошибку. Система рекомендует использовать для базы данных и таблиц в ней – сопоставление “utf8_bin”

Как проверить кодировку базы данных и таблиц Jira в Mysql?

Коннектимся к базе текущим пользователем Jira:

# mysql -u jirauser -p

Потом выбираем базу данных:

mysql> use jiradb;
Database changed

Проверяем базу:

mysql> SELECT default_collation_name
    FROM information_schema.schemata S
    WHERE schema_name = (SELECT DATABASE()
    FROM DUAL);
+------------------------+
| default_collation_name |
+------------------------+
| utf8_general_ci |
+------------------------+
1 row in set (0,00 sec)

Проверяем таблицы:

mysql> SELECT DISTINCT C.collation_name, T.table_name FROM information_schema.tables AS T, information_schema.`collation_character_set_applicability` AS C WHERE C.collation_name = T.table_collation AND T.table_schema = DATABASE();

...
 | utf8_general_ci | qrtz_calendars |
 | utf8_general_ci | qrtz_cron_triggers |
 | utf8_general_ci | qrtz_fired_triggers |
 | utf8_general_ci | qrtz_job_details |
 | utf8_general_ci | qrtz_job_listeners |
 | utf8_general_ci | qrtz_simple_triggers |
 | utf8_general_ci | qrtz_trigger_listeners |
 | utf8_general_ci | schemepermissions |
 | utf8_general_ci | searchrequest |
 | utf8_general_ci | serviceconfig |
 | utf8_general_ci | sharepermissions |
 | utf8_general_ci | tempattachmentsmonitor |
 | utf8_general_ci | trackback_ping |
 | utf8_general_ci | trustedapp |
 | utf8_general_ci | upgradehistory |
 ...

Да, действительно, проблема есть.

Смена кодировки базы данных и таблиц Jira в Mysql

В документации Jira написано, что нужно создать вторую базу с нужно кодировкой, и скопировать все таблицы в неё. Однако, это неудобный способ. После этого придётся перенастраивать Jira через bin/config.sh (который требует для запуска java, а у нас только консольный сервер) или создавать файл dbconfig.xml , которого нет изначально и нельзя просто отредактировать его, чтобы поменять имя базы данных. Поэтому вот лучший способ:

1. Останавливаем Jira сервер:

# /etc/init.d/jira stop

2. Делаем дампы базы (один – будет резервный):

# mysqldump -u jirauser -p jiradb > jiradb.sql
# mysqldump -u jirauser -p jiradb > jiradb_backup.sql

3. Заменяем “CHARSET=utf8” на “CHARSET=utf8 COLLATE=utf8_bin” во первом дампе с помощью вашего любимого текстового редактора (вполне подойдёт nano):

# nano epic_jira.sql

4. Коннектимся рутом в mysql (мы на сервере под управлением Plesk Onyx, поэтому такая чудная команда):

mysql -uadmin -p`cat /etc/psa/.psa.shadow`

5. Удаляем базу:

mysql> DROP DATABASE jiradb;

6. Создаём новую базу с нужной кодировкой “utf8_bin”:

CREATE DATABASE epic_jira CHARACTER SET utf8 COLLATE utf8_bin;

7. Даём права пользователю (на всякий случай):

GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX on jiradb.* TO 'jirauser'@'localhost' IDENTIFIED BY 'PaSSwoRD12345';
 flush privileges;

8. Также, можно проверить привилегии:

mysql> SHOW GRANTS FOR jrepicint@localhost;

9. Далее, в консоли заливаем базу:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -h localhost jiradb < jiradb.sql

10. Запускаем Jira сервер:

# /etc/init.d/jira start

Можно также проверить кодировки, как описывалось вначале. В любом случае, вы увидите состояние базы, если зайдёте по адресу:

http://ваш-jira-сервер/plugins/servlet/stp/view/?source=notification

 

Шаблоны для Yii2 на Vesta CP – бэкенд и фронтенд варианты.

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

Совсем красиво сделать не получилось, потому что нужно, чтобы бэкенд и фронтенд смотрели в одну папку с подпапками. Этого нельзя добиться только правкой шаблонов. Это можно понять, взглянув на их синтаксис, который обрабатывается скриптами, вроде v-add-web-domain.

Вот код на гитхаб.

Шаблоны и скрипт работают, исходя из того, что: фронтенд лежит здесь -> /home/$USER/web/$DOMAIN/public_html/frontend/web бэкенд лежит здесь -> /home/$USER/web/$DOMAIN/public_html/backend/web

Инструкция

(1)
Добавьте директории “apache2” и “nginx” из репозитория гитхаб (о котором упоминается выше) в /usr/local/vesta/data/templates/web/ (в CentOS/RHEL возможно, придётся переименовать “apache2” в “httpd”) Добавьте yii2-cconf.sh скрипт в любое, нужно вам место на сервере.

(2)
В контрольной панели Vesta CP вы можете создать оба домена:
example.com
backend.example.com

После этого в Vesta CP вы можете отредактировать настройки доменов и устновить шаблоны:
yii2-frontend для example.com и yii2-backend для backend.example.com

(3)
В конце вы можете запустить yii2-cconf.sh скрипт с помощью команды:
( cd your-some-directory/ )
bash ./yii2-cconf.sh vestacpuser example.com

Как разблокировать ip-адрес, заблокированый Fail2ban

Как разблокировать ip-адрес, заблокированый Fail2ban, картинка

Как системному администратору, мне трудно себе представить спокойную жизнь без Fail2ban.

Этот сервис отслеживает логи многих служб, таких как веб-сервер, почтовый сервер, openssh-сервер и так далее. В случае подозрительной активности (как правило, много неудачных авторизаций), он автоматически блокирует (используя правила iptables) на заданное время ip-адрес, с которого были эти авторизации. Настройка Fail2ban – это отдельная тема.

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

1. Нужно залогиниться по ssh под другим ip-адресом на сервер под root (либо под другим пользователем, но потом выполнить процедуру “su -“, чтобы получить root-права).

2. Чтобы увидеть, какие IP-адреса заблокированы, набрать следующую команду:
iptables -L -n
если вывод команды очень длинный, то можно так:
iptables -L -n | less

3. Далее найти цепочку fail2ban-ssh (мы говорим о блокировке по ssh, если другая служба – искать соответствующую цепочку), где и должен быть наш IP:
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0

4. Чтобы удалить IP адрес из блокировки Fail2ban, нужно выполнить следующую команду (aa.bb.cc.dd – IP, который нужно разблокировать):
iptables -D fail2ban-ssh -s aa.bb.cc.dd -j DROP

После этого пользователь сможет вновь подключиться к серверу по ssh.

Страницы:1234567...14