7 ответов в этой теме

[K0S]

Добрый день.

Внезапно DrWebControl Center перестал пускать в админку. После ввода логина/пароля получаем:

Authorization failed.  User not found

 

 

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

База в Postgresql через odbc

Куда копать в таком случае?

Прикрепленные файлы:

•  drweb_error.png   26,25К   0 Скачано раз

Сообщение было изменено K0S: 03 Апрель 2013 - 09:06

[Kirill Polubelov]

Конечно в логи! Но, перед тем, сделайте пару вещей:

-- очистите куки и кэш броузера;

-- очистите сессии в ЕС-сервере (удалите содержимое подкаталога sessions в подкаталоге var рабочего каталога сервера);

-- повторите попытку входа;

 

Если есть возможность, с целью локализации проблемы - попробуйте зайти с др. броузера (например, Firefox).

Если описанные действия не помогли, надо смотреть лог сервера drwcsd.log (в каталоге var).

 

Если самостоятельно, по логу, установить причину не получится, перед выкладыванием лога сюда, следует учесть, что он может содержать приватные данные. Поэтому либо фрагмент лога, где по вашему обнаруживается проблема, либо через техподдержку.

 

Выяснение проблемы будет идти легче, если лог будет уровня ALL ("Детальный протокол").

 

P.S.: могу немного погадать без логов - не случилось ли это после обновления драйверов ODBC?

Сообщение было изменено Foxes: 03 Апрель 2013 - 09:56

[K0S]

Конечно в логи! Но, перед тем, сделайте пару вещей:

-- очистите куки и кэш броузера;

-- очистите сессии в ЕС-сервере (удалите содержимое подкаталога sessions в подкаталоге var рабочего каталога сервера);

-- повторите попытку входа;

 

Если есть возможность, с целью локализации проблемы - попробуйте зайти с др. броузера (например, Firefox).

Если описанные действия не помогли, надо смотреть лог сервера drwcsd.log (в каталоге var).

 

Если самостоятельно, по логу, установить причину не получится, перед выкладыванием лога сюда, следует учесть, что он может содержать приватные данные. Поэтому либо фрагмент лога, где по вашему обнаруживается проблема, либо через техподдержку.

 

Выяснение проблемы будет идти легче, если лог будет уровня ALL ("Детальный протокол").

 

P.S.: могу немного погадать без логов - не случилось ли это после обновления драйверов ODBC?

Драйвера ODBC и правда были обновлены несколько дней назад. Скорее всего изза этого, т.к. больше никаких работ на этом сервере не проводилось за последнее время.

В логе drwcsd.log стандартного уровня ничего подозрительного нет.

 

Куки и кэш броузера почистил, файл сессий чем-то заблокирован, и не удаляется (drwcsd останавливал разумеется), перезагружать сервер не могу днем.

 

А что, кто-то уже встречался с похожей проблемой (драйверы odbc)?

Сообщение было изменено K0S: 03 Апрель 2013 - 11:55

[Kirill Polubelov]

K0S, к сожалению, PostgreSQL, как свободно распространяемая СУБД, не лишена некоторых недостатков. А именно - не все версии драйверов ODBC работают полностью корректно. Поэтому, у нас в Release Notes к ЕС-серверу 6.0.4 указаны конкретные версии драйверов ODBC x86/x64 с которыми будет работать нормально. 99,(9)%, что вы столкнулись именно с той версией драйверов, которые не совсем корректно работают.

Вот цитата из RN для ЕС 6.0.4:

"На 64-х разрядных платформах для работы Enterprise Cервера с СУБД PostgreSQL версии 9.x через ODBC следует использовать 64-х разрядный ODBC-драйвер версии 09.00.0310. Работа с СУБД PostgreSQL версии 8.x через ODBC не поддерживается. 

 

Для работы на 32-х разрядных платформах через ODBC с СУБД PostgreSQL, в том числе 9-й версии (х86/x64), следует использовать 32-х разрядный ODBC-драйвер версии 08.04.0200. Работа с драйверами более старших версий не гарантируется."

Это не означает, конечно же, что обязательно со всеми остальными версиями будет некорректная работа. Это означает, что с указанными версиями можно ожидать корректную работу.

Могу добавить, что скорей всего и с 09.00.0310 х86 драйвером тоже будет корректная работа.

[K0S]

Спасибо. Кто бы мог подумать... Откат на psqlodbc 09.00.0310 x64 вернул нам админку. Вообще обновлялся потому-что этот драйвер не хотел работать через pgbouncer, но и с новым драйвером ничего не изменилось. Всеже думаю лишним не будет поднятие этой темы на форуме.

Сообщение было изменено K0S: 05 Апрель 2013 - 11:06

[Kirill Polubelov]

Конечно не лишним - ведь это помогло вам решить проблему, может и еще кому-то пригодится.

 

>> файл сессий чем-то заблокирован, и не удаляется (drwcsd останавливал разумеется),

 

Опять таки, попробую угадать Самозащита ЕС-агента, установленного там же, где и ЕС-сервер, не была отключена в момент попытки очистки сессий? Впрочем, теперь это не важно, если только на будущее, А сессии можно очищать,не останавливая ЕС-сервер.

[Kirill Polubelov]

>>  Вообще обновлялся потому-что этот драйвер не хотел работать через pgbouncer, но и с новым драйвером ничего не изменилось.

 

Пробовали разные режимы? Судя по табличке "Supported PostgreSQL features." из http://wiki.postgresql.org/wiki/PgBouncer не все фичи будут работать в разных режимах. Возможно, что ODBC использует какие-то из них и они для него критичны. К сожалению, не могу сказать какие именно.

[K0S]

>>  Вообще обновлялся потому-что этот драйвер не хотел работать через pgbouncer, но и с новым драйвером ничего не изменилось.

 

Пробовали разные режимы? Судя по табличке "Supported PostgreSQL features." из http://wiki.postgresql.org/wiki/PgBouncer не все фичи будут работать в разных режимах. Возможно, что ODBC использует какие-то из них и они для него критичны. К сожалению, не могу сказать какие именно.

В данном случае PgBouncer ругается на "unsupported startup parameter: geqo=on". Разбираться дальше что-то нет ни времени ни желания (параметра настройки по этому поводу у pgbouncer'а нету), в принципе drweb ЕС-сервер держит постоянно отрытыми две сессии и этого ему хватает.