Вот сервис в сети OpenFire — цель которого управление корпоративным общением на рабочие моменты, обсуждения, личные моменты и т.д.
А что если вдруг понадобиться изменить пароль на административную учетную запись, как быть в этом случае — причины ведь могут быть разными, увольняется сотрудник твоего отдела, обычная забывчивость или ты приходишь в новую контору сервис есть, а как в него войти никто не знает или знает но он уволился и ничего говорить не хочет.
Какие варианты у меня есть для этого:
1) Сбросить пароль на суперпользовательскую учетную запись mysql, но или предположим что этот пароль все же есть.
2) По конфигурационному файлу узнаем с какими портами для доступа в Административную часть можно работать:
ekzorchik@srv-host:~$ sudo nano /etc/openfire/openfire.xml
<adminConsole>
<!-- Disable either port by setting the value to -1 -->
<port>9090</port>
<securePort>9091</securePort>
</adminConsole>
далее в этом конфигурационном файле будет отображено как работает openfire по части базы:
<defaultProvider>
<driver>com.mysql.jdbc.Driver</driver>
<serverURL>jdbc:mysql://localhost:3306/db_openfire?
И так он работает с внешней базой развернутой на этом хосте где и само приложение, также известно что база именуется, как db_openfire — что это уже что-то, а <driver> это имя класса по работе с базой
2) Далее я бы советовал сделать бекап всей базы на случай если не правильно произойдет процедура сброса/изменения пароля:
ekzorchik@srv-host:~$ sudo mysqldump -u root -p712mbddr@ db_openfire > db_openfire.sql
ekzorchik@srv-host:~$ ls -lh db_openfire.sql
-rw-rw-r-- 1 ekzorchik ekzorchik 39K Dec 7 06:48 db_openfire.sql
А в дополнение желательно на тестовой площадке конкретно для этой установленной версии openfire проработать шаги по восстановлению из бекапа:
ekzorchik@srv-host:~$ mysql -u root -p712mbddr@
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 41
Server version: 5.5.53-0ubuntu0.14.04.1 (Ubuntu)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| db_openfire |
| mysql |
| performance_schema |
+--------------------+
4 rows in set (0.01 sec)
А теперь посмотрим какие вообще пользователи базы данных mysql имеются:
mysql> select user,host from mysql.user;
+------------------+-----------+
| user | host |
+------------------+-----------+
| root | 127.0.0.1 |
| root | ::1 |
| debian-sys-maint | localhost |
| openfire | localhost |
| root | localhost |
| root | srv-host |
+------------------+-----------+
6 rows in set (0.00 sec)
можно предположить что это учетная запись openfire — вряд ли кто-то будет все запускать под суперпользователем, правда такой вариант исключать нельзя.
Подключаюсь к базе, см. какие есть таблицы и вывожу какие имеются пользователи:
mysql> use db_openfire;
mysql> show tables from db_openfire;
Посмотреть структуру таблицы:
mysql> desc ofUser
mysql> select username,plainPassword,email from ofUser;
+----------------+---------------+--------------------------+
| username | plainPassword | email |
+----------------+---------------+--------------------------+
| admin | NULL | ekzorchik@ekzorchik.ru |
| alektest | NULL | alektest@polygon.local |
| alexander.ollo | NULL | alexander.ollo@polygon.local |
+----------------+---------------+--------------------------+
3 rows in set (0.01 sec)
mysql> update ofUser set plainPassword='Aa1234567', encryptedPassword=null where username='admin';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> quit;
Bye
ekzorchik@srv-host:~$ sudo service openfire restart
После открываю Web-консоль администрирования и пробую зайти с новым паролем:
https://10.7.8.175:9091/
И я успешно был авторизован с измененными аутентификационными
данными:
Работает, а по другому и быть не может это ведь отрепетированные шаги по обслуживанию своего настроенного. Теперь мне не страшны сотрудники которые как бы выразиться по корректнее – «Не надежны», главное что если они и сделаю пакость, я смогу восстановить из бекапа либо сбросить пароль на административную учетную запись. Только вот бекап нужно делать в два различных места. И раз в неделю проверять его работоспособность на восстановление, резервная копия без уверенности что она рабочая это всего лишь мнимая уверенность. А пока я прощаюсь, с уважением Олло Александр aka ekzorchik.