Вступление:
Есть какая-то убожеская программа, писанная на питоне, работает с Firebird-ом 1.5.6 (классик). В центральном офисе на сервере работают одновременно с 3-мя БД: (своя, 1-ого филиала, 2-ого филиала). На филиалах создается резервная копия БД gbak-ом, пересылается по почте на центральный офис. Здесь тем же gbak-ом идет восстановление БД из присланной резервной копии. На центральном офисе работают с офф-лайн копией филиальной БД, поэтому изменений не вносят, просто формируют какие-то отчеты. Теперь суть проблемы: Когда начинаю процесс восстановления БД - выдает ошибку, т.к. база кем-то занята. По имени пользователя установить пользователя, сидящего в БД невозможно из-за дебильности самой программы - все юзеры как на центральном офисе, так и на всех филиалах работают под SYSDBA/masterkey, причем строка подключения записана в самописных библиотеках питона, код которых недоступен. Остается выход один - вычислять по IP-адерсу или имени компьютера. И даже нашел такую программу - InterBase Connections. В ней можно закрыть соединение по IP-адресу, но нет возможности глянуть к какой БД подключен пользователь. В итоге надо или рубить всех, кто потенциально там засиживается, либо обзванивать всех и просить выйти из БД филиала. Пока обзвонишь последнего - первый уже опять залезет.
Хотелось бы иметь нечто, что сначало выкинуло всех из указанной БД, а потом уже запустило gbak.
Есть какие-то соображения по этому поводу?

> fearless   (19.04.10 12:38)  


> работают одновременно с 3-мя БД: (своя, 1-ого филиала, 2-
> ого филиала)

Oo кошмар.. так трудно наладить репликацию??

> Хотелось бы иметь нечто, что сначало выкинуло всех из указанной
> БД

database shutdown

> turbouser ©   (19.04.10 12:48) [1]


> работают под SYSDBA/masterkey

А..
тогда shutdown не поможет..

В FB 2.1 есть табличка MON$ATTACHMENTS с информацией о коннектах..
если же нельзя перейти с 1.5 то остается только смотреть кто подключен к порту FB (3050 по умолчанию) например утилиткой tcpview

shutdown не помогает, только что опробовал((

На FB 2.1 пытался перейти - не хочет, вываливает огромное кол-во ошибок в консоль отладки. Кто подключен к порту - узнать не проблема, а вот кто к какой БД подключен - вот в чем вопрос. Т.е. из одной базы можно легко выкинуть пользователя (т.к. она посути оффлайн версия актуальной базы), а вот с другой (БД самого офиса) такой фокус делать нельзя (пропадут еще не дай бог какие-то бесценные наборки).

> fearless   (19.04.10 15:07) [4]

Тогда административно всем объявить - "с 2-х до 3-х у нас на сервере профилактика. Все соединения с бд будут автоматически сброшены. Кто не успел - ССЗБ"
Но все-таки лучше соорудить нормальную репликацию и работать с одной бд.

Можно запускать восстановление ночью, по расписанию.

> Sergey13 ©   (19.04.10 15:36) [6]
>
> Можно запускать восстановление ночью, по расписанию.
>

А если кто-то не закрыл на ночь программу и коннект болтается?
IMO надо официально предупредить пользователей, чтоб отключались, а в заданный час restart service & backup -)

Хотя, бардак это, конечно.. Мало того, что юзеры с админскими правами работают, так еще и пароль админский стандартный.. да еще и куча баз..

>> turbouser

Совершенно согласен (на счет бардака). И если бы была какая-нибудь номинация "Самая дебильная программа года" - это убожище всегда бы брало там Гран-при.

С правами там вообще весело: имен пользователей там нет, есть только пароли, прежде чем создать пользователя надо придумать ему уникальный цифровой пассворд. А если надо дать какие-то особые права на некоторые проводки/операции и т.п. - тогда только через разработчиков. Высылают несколько обновленных скриптов (а их там 6500!!!), в которых будет прописано приблизительно следующее:

если (пароль = '123') тогда делать то-то.... // 123 - это пароль главбуха, ему эта операция разрешена
иначе МесседжБокс('Доступ запрещен')

Кстати, все это зовется "Система управления предприятием"

> причем строка подключения записана в самописных библиотеках питона, код которых недоступен.
этого не может быть, питон скриптовый язык, если нет исходников то должны быть скомпилированные в его байт-код модули (которые должны нормально "раскомпилироваться", правда не знаю как, не занимался этим (подозреваю что аналогично фохпрошному разборшику, чем занимался раньше, и есть утилита для этого)), если же используется левая "сборка в exe" то она у него тоже разбирается (там что-то типа архива из тех же модулей + интерпретатор питона).

>>sniknik
строчка ....sysdba ....... masterkey.... содержится в файле password2.pyc
что здесь такого невозможного?

Файл действительно скомпилирован в питоновский байт-код. Декомпилятор питона когда-то видел на сайте, он тоже писан на питоне. В общем не было ни времени ни желания разбираться с этой фигней. Да и смысл какой? Поменять имя пользователя/пароль по умолчанию разве что. Ну будет не sysdba, а ivan, не masterkey, а pupkin. Но его все равно прийдется сделать администратором БД (иначе что-нибудь, но неприменно перестанет там работать). Главная проблема - права доступа раздаются на уровне скриптов, а не БД, и она ведь от этого не уйдет.

Начал копать в сторону репликации БД.

> ... содержится в файле password2.pyc
> что здесь такого невозможного?
не невозможно то, что содержится, невозможно то что код не доступен... т.к. этот файл из байткода должен легко "разбираться" в обратку. и + для питона, даже с форматированием (отступы), т.к. у него это часть синтаксиса.