При перезапуске сервера связь с главным необратимо уходит в offline
#1
Отправлено 26 Сентябрь 2019 - 21:18
#2
Отправлено 27 Сентябрь 2019 - 09:53
Подскажите пожалуйста, что делать?
Поделиться логами сервера с verbosity=all с попавшим в них воспроизведением проблемы.
#3
Отправлено 02 Октябрь 2019 - 21:52
Прикрепленные файлы:
#4
Отправлено 03 Октябрь 2019 - 10:08
Ваше замечание про сертификат очень кстати.
После установления связи сервера обмениваются актуальными сертификатами, так вот главный отдаёт какой-то другой сертификат, возможно, даже от другого закрытого ключа. Причём даже если в настройках связи отсутствует актуальный сертификат, на старте сервер всё равно должен туда добавлять его,
Так что вопросы к держателям главного:
1. Вот этот сертификат, с которым создаётся связь на подчинённом, и etc/drwcsd-certificate.pem на главном – это один и тот же файл с точностью до байта, верно?
2. На какой СУБД работает главный сервер? Я посмотрел, правда на 11.0.2 – актуальный сертификат в настройки связи добавляется, если его там нет. На главном похоже это не происходит. Кстати, хотелось бы в связи с этим взглянуть на детальный лог главного сервера на момент его запуска.
3. Не пропадёт ли обсуждаемая проблема, если вручную в настройках этой связи на главном добавить его же сертификат в "Собственные сертификаты Сервера", после чего пересоздать связь на подчинённом или заново подкинуть сертификат?
Собственно,
— правильный сертификат – размером 681 байт (или около того) и с телом, начинающимся с "MIIByTCCAXa",
— неправильный – 685 байт и "MIIByzCCAXi" соответственно.
Больше я про правильный ничего не знаю, так что больше подробностей для визуального сравнения не дам.
#5
Отправлено 03 Октябрь 2019 - 17:58
#6
Отправлено 03 Октябрь 2019 - 18:28
В общем, всё сводится к тому, чтоб понять, откуда берётся на главном сервере неправильный сертификат главного сервера, и как с этим бороться.
п.3 - после пересоздания связи на Главном, связь переходит в онлайн (без действий на подчиненном), но временно.
А вот этого кстати не должно быть, если никто не трогает уже упавшую связь на подчинённом. Потому что подчинённый уже потерял к тому моменту правильный сертификат главного.
#7
Отправлено 03 Октябрь 2019 - 18:57
В сомнении... извиняюсь, если не так ....
Сертификат главного на подчиненном мы добавляли руками в свойствах связи выбором файла
Сообщение было изменено dr_user: 03 Октябрь 2019 - 18:58
#8
Отправлено 03 Октябрь 2019 - 19:11
Сертификат главного на подчиненном мы добавляли руками в свойствах связи выбором файла
Да, с этим понятно, тот сертификат нормальный.
Тут такая штука. На каждой стороне связи есть по два набора сертификатов:
1) сертификаты соседнего сервера – нужны, чтобы аутентифицировать этот соседний сервер (то есть не допустить работы с подставным сервером);
2) собственные сертификаты – нужны, чтобы передать на соседний сервер после установления связи (допустим, мы хотим заменить сертификат – тогда добавляем его вторым, он приезжает соседу, потому что тот доверяет первому сертификату – и вот он доверяет двум сертификатам, потом старый выкидываем – готово).
Проблема тут возникает после обмена сертификатами, главный говорит, что у него вот такой-то сертификат, хотя работает он на самом деле с другим сертификатом.
Решиться эта проблема должна сама, почему не решается – надо разобраться. И в качестве workaround – добавить правильный сертификат в собственные сертификаты именно главного, раз он сам этого не делает. Но раз что-то пошло не так, то может быть workaround тоже не взлетит.
Да, если workaround внезапно поможет – всё равно хочется выяснить корень проблемы. Не нравится нам "так это ж DrWeb, так и будет ...".
#9
Отправлено 03 Октябрь 2019 - 19:46
Супер-фишка - картинки прилагаются:
Два файла сертификатов: 50… правильный подчиненного, 60… правильный главного.
Оба начинаются на MIIByTCCAXa.
Если в свойствах связи два раза выбрать 2й файл, то в «Сертификатах соседнего»
видим ДВА РАЗНЫХ сертификата, один из них 60….
Так что держателям главного сообщаем конкретный номер кривого сертификата. Теперь уж должны исправить.
Спасибо!!
Прикрепленные файлы:
#10
Отправлено 03 Октябрь 2019 - 20:12
Теперь уж должны исправить.
Есть подозрение, что нам тоже надо что-то исправить. Подобная ситуация должна исправляться на каждом старте сервера. Я уж не думаю, что у главного там вечный аптайм, а сертификаты меняются сами по себе в процессе работы.
#11
Отправлено 08 Октябрь 2019 - 11:59
Есть новости?
#12
Отправлено 08 Октябрь 2019 - 12:13
Все печально. Не особо хотят что-то у себя менять...
В связи с этим вопрос - работа с сервером из командной строки: можно ли как-то заменять сертификат головного?
(аналог через WEB: в свойствах связи выбрать файл, сохранить).
Не через автокликеры извращаться, а как то штатно?
... раз в сутки менять, так "с костылем" и работать ...
#13
Отправлено 08 Октябрь 2019 - 13:39
Не особо хотят что-то у себя менять...
Делиться информацией о проблеме – тоже? Это да, печально.
Но по возможности попинывайте ответственных. Можете ссылаться на нас.
... раз в сутки менять, так "с костылем" и работать ...
Да ну, можно ж проще. В планировщике заданий сервера создать задание, лучше даже ежечасное, на запуск скрипта такого вида:
local cert = dwcore.str_quote( [[-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ]]) local db = database.get() if not db or not db.begin() then return end local osid = drwcs.license_key().uuid local now = dwcore.db_nowstamp() local ids = db.exec( "SELECT DISTINCT id FROM servers WHERE osid=?", {false}, {osid} ) if not ids then return end for _,id in pairs(ids) do local rez = db.exec( "SELECT COUNT(*) FROM servers WHERE osid=? AND id=? AND name=? AND value=?", { true }, { osid, id[1], 'cert', cert } ) if rez and rez[1][1] == 0 then db.exec( "INSERT INTO servers(osid,id,name,value,updatetime) VALUES(?,?,?,?,?)", nil, { osid, id[1], 'cert', cert, now } ) end end db.commit()
Набросал навскидку, мог где-то наврать. Проверьте, пожалуйста.
Тело правильного сертификата подставить между квадратными скобками целиком как есть.
Сообщение было изменено Afalin: 08 Октябрь 2019 - 13:39
#14
Отправлено 08 Октябрь 2019 - 19:31
Спаасибо! Работает!
- при выполнении скрипта через Lua-консоль связь оживает, вешаем на планировщик
Да ну, можно ж проще.
... дык не руками ж, думали про шедулер, только внешний
#15
Отправлено 08 Октябрь 2019 - 19:36
как то получился дубликат - удален
Сообщение было изменено dr_user: 08 Октябрь 2019 - 19:39
Читают тему: 0
0 пользователей, 0 гостей, 0 скрытых