Намудрили - чёрт ногу сломит, короче.

Вот в нашей многосерверной системе, раскиданной по 25+ регионам нашей Родины, надо чтоб все со всеми соединялись независимо от версии Firebird. Одновременно во всех 200+ организаций-клиентов невозможно проапгрейдить системы.
И клиенты от 3.0 к старым серверам 2.5, и старые клиенты 2.5 к обновленным серверам 3.0 чтоб цеплялись без проблем. И с минимальными телодвижениями по юзерам-паролям. Чтоб сохранились все явки-пароли - перекочевали из 2.5 в 3.0 при переходе на 3.0. Ибо на каждом сервере при апгрейде перебивать десятки пар логин/пароль в Srp вручную тупо некому. Весь процесс апгрейда должен быть автоматизирован по максимуму.
А "изкаропки" это не работает.

Наметки по скрипту переноса юзеров из security2.fdb в Legacy_UserManager уже делали тут.
Не знаю, несколько месяцев не возвращался к этому вопросу. Включен ли такой скрипт-конвертилка security2.fdb --> security3.fdb в инсталлятор?

Да, это я и имел в виду. Помню, конечно. Про него и говорил.

hvladИзменение 3 строк в конфиге сервера - это намудрили ?
Давайте перестанем латать старые дыры ???
Мне кажется просто, что дефолтные настройки должны были бы обеспечивать максимальную совместимость с предыдущими версиями. И я предпочел бы "править три строки конфига" только тогда, когда мне понадобились бы новые фичи или даже в инсталляторе был бы вопрос, обеспечивать ли совместимость со старыми клиентами и обеспечивать ли возможность коннекта к старым серверам. Чтоб мне как пользователю не задумываться над ручной правкой конфига при апгрейде. Апгрейд - ведь это это как правило ночь (улица, фонарь, аптека...)

А в существующем варианте элементарная замена Firebird SQL с 2.5-->3.0 (ессессно, с b/r баз) с нынешним умолчательным конфигом делает базы, им обслуживаемые, недоступным для внешних старых клиентов 2.5 со своими неизменными логинами и паролями.
И это огромный головняк мне как админу многосерверной системы. У нас 200+ серверов в самых непредсказуемых отношениях между собой (есть и автономные и даже однопользовательские, конечно). Более 3000 взаимных связей. Процедура апгрейда security2.fdb --> security3.fdb, описанная в RN 3.0 нам не подходит. Она не сохраняет старые пароли. Нет возможности быстро и надежно менять пароль юзера на 199 серверах и в настройках программ 199 систем при апгрейде 200-го сервера.
И вот я должен теперь сочинять самому себе инструкцию, чего бы мне не забыть сделать при апгрейде на 3.x, чтоб и к этому обновленному серверу коннекты без проблем приходили со старых клиентов 2.5, и с этого компа к другим серверам 2.5 клиентские обращения клиентом от 3.х выполнялись.

Апгрейд security.fdb --> security2.fdb при переходе с 1.5 на 2.x и тот выглядел более явным и дружелюбным.
А тут и правка конфигов до кучи ещё.
Уже одно только то, что обсуждения на тему коннекта "клиент 3.x" -> "FB 2.x" и "клиент 2.x" -> "FB 3.x" возникают тут регулярно, говорит о том, что настройки непрозрачны, неочевидны и дефолтное поведение свежеустановленного FB 3.0 неожидаемое.

o_v_aЧтоб сохранились все явки-пароли - перекочевали из 2.5 в 3.0 при переходе на 3.0Бекап security2.fdb, рестор security3.fdb - не работает ?[/quot]
Вот это поворот... А сработает? Я не смотрел в формат security3 и отличия от security2 - сразу признаюсь...
То есть никакой упомянутый тут скрипт переноса в Legacy_UserManager не нужен? Чё ж раньше - в той теме - молчал?

P.S. От FB 1.5 вроде мы везде вроде избавились уже. И то хорошо.
Но когда у нас хватит духу шагнуть в мир 3.x, я не предскажу даже. Может быть и пропустим, а сразу занырнем в 4.0. И основная проблема - это как раз непрозрачность авторизации. Руки не доходят ощупать все досконально и уложить всё в голове как делает это сейчас Дмитрий. Только применительно к своим системам.

Гаджимурадов Рустамo_v_a> И клиенты от 3.0 к старым серверам 2.5, и старые клиенты
o_v_a> 2.5 к обновленным серверам 3.0 чтоб цеплялись без проблем.
А вы щас на какой версии сидите, 2.5 ?
Да. От 2.5.3 до 2.5.6 - у кого как.

hvlado_v_aМне кажется просто, что дефолтные настройки должны были бы обеспечивать максимальную совместимость с предыдущими версиями.Так и есть. Кроме вопросов безопасности
Если такая забота о безопасности рушит всю существующую систему межсерверного взаимодействия в многосерверных системах, которая основана на условной стабильности логинов/паролей юзеров на разных серверах в составе системы, то сомнительна польза от такой заботы.
Я бы предпочел, чтоб меня спросили , хочу ли я, чтоб позаботились о моей безопасности или я "сам себе злобный буратино" и отдаю отчет в последствиях отказа. Ибо при апгрейде работоспособность системы первична, а всякие вопросы безопасности вторичны.