|
Страница 22 из 38
Прочие странности и неприятности Вложенность вызовов Коль скоро что-то можно вызывать вложенно, то возникает вопрос, сколько раз, и до каких пределов. Насколько мне известно из опыта, максимальная вложенность вызова триггеров находится в диапазоне 6-8 (хотя в 5.5 её по слухам раздули до 700-1000). Выяснилось это при реализации каскадного удаления. То есть клиент удаляет запись, запускается триггер, удаляет другую запись, запускается триггер, ... и так до ошибки. Процедуры же можно вызывать до 1000 раз. По крайней мере, так говорит официальная документация. Собственно, описанный глюк именно через процедуры и разрешился. То есть теперь в нашем проекте триггера каскадного удаления ничего сами не удаляют, а вызывают процедуры sp_bd_xxxx. И вложенные вызовы идут уже между ними. Установка, переустановка и гроханье Linux Документация Борланда гласит, что ставить InterBase 4.0 можно только на Red Hat 4.2. А 5.6 - под Red Hat 6.0. И то, и другое - большое гадство. Изо всех дистрибутивов выбрали самый дорогой коммерческий и изо всех сил пытаются привязаться к нему. Самое интересное, что и в Slackware, и в Debian, и в RedHat 5.1 четвёрка ставится совершенно одинаково и нормально работает. Что действительно зависит от диструбитива, так это interbasePerl - он (0.5) у меня почему-то ожил только под Slackware. С 5.6 всё оказалось сложнее - эта версия скомпилирована с glinterbasec 2.1. Самое обидное, что для реальной работы никаких специфических функций этой библиотеки не требуется - я смотрел импорты. Всё то же самое, могли бы скомпилировать и с glinterbasec 1.0, как четвёрку. Стянуть свежий glinterbasec можно с ftp://prep.ai.mit.edu/pub/gnu/glinterbasec/. Только вот дело это нелёгкое - похуже ядра. Одного места на диске для сборки понадобится 400 МБ. И дополнительные пакеты придётся стянуть из других мест. В общем, если страшно, но хочется поставить, можете попросить скомпилированный пакет у меня. Поставляется дистрибутив в довольно странном виде: .tar, а внутри ещё один .tar + install + readme. Внешний .tar надо распаковать в какой-нибудь временный каталог и запустить install из-под root'а. Инсталлятор фактически представляет собой скрипт, который спрашивает, куда ставить и распаковывает второй .tar туда, куда сказали. Попутно он правит /etc/inetd.conf и /etc/services, чтобы прописать новый сервис. Здесь есть одна детская неожиданность: при попытке поставить в самое логичное место - /usr/interbase инсталлятор заявил, что непосредственно туда поставить не может, а поставит в /usr/interbasease/i586...всякая_фигня.../, а потом сделает ссылку /usr/interbase -> /куда/реально/поставил. И самое интересное, что обещание выполнил и всё запахало. Только вот никак не пойму, зачем это? Далее надо сообщить inetd, что его конфигурация изменилась. Те, кому лень думать могут тупо перезагрузить систему. Кто поумнее сделает kill -HUP номер_процесса_inetd или что-то подобное.
На этом официальная установка заканчивается, и начинается ручная доводка. Дело в том, что после установки все процессы InterBase запускаются под root'ом и имеют неограниченные права. И соответственно все обращения к диску, все создаваемые базы числятся под root'ом. В сочетании с глюком всех InterBase'ов - возможностью клиентов произвольно создавать базы в любом месте файловой системы - получается страшное оружие для чайников. В других, менее защищённых системах это еще можно понять, но в Unix - просто хамство. Таким образом, нужно срочно (а ещё лучше - заранее) создать специального пользователя (скажем, iserver), заблокировать ему вход в систему и переподчинить всё, что инсталлятор понаставил: chown iserver.users /куда/поставлено. Потом надо ещё переправить /etc/inetd.conf, заменив root на iserver в строке для gds_db. После этого будет пахать гораздо безопаснее (в том смысле, что взломавший InterBase ничего кроме баз не запортит), но нужно следить, чтобы файлы БД имели доступ rw для этого самого iserver. В качестве альтернативы можно предложить занести всех без исключения пользователей Unix в InterBase, причём сообщив uid каждого из них. В этом случае серверные процессы пользователей будут работать из-под правильного uid и всё тоже нормализуется. Однако как только найдётся пользователь, не прописанный в interbase, он получит права root'а. Уж лучше бы они сделали переключение на nobody, как, например, в Apache. Борланд врёт, что данному серверу требуется 32 МБ памяти. На самом деле требуется примерно 2-3 МБ на активное подключение, то есть цифра 32 соответствует примерно 10 одновременно работающим клиентам. Если клиенты готовы терпеть лёгкое торможение, то можно и по 1 МБ на человека. С учётом того, что ядру Linux нужно около 4 МБ для собственного счастья, этот сервер должен быть работоспособным, начиная примерно с 8 МБ. С большим удовольствием сообщаю, что версия 5.6 оказалась практически ничем не более жручей, чем 4.0. Вот если бы все программы так развивались ... Грохнуть достаточно просто: - Убрать ссылки на InterBase (gds) из /etc/inetd.conf и /etc/services.
- Оповестить inetd так же, как и при установке.
- Грохнуть ветку каталогов и, возможно, символическую ссылку, которые создал инсталлятор.
- Грохнуть повисшие символические ссылки /usr/linterbase/linterbaseg...so, созданные инсталятором.
- Грохнуть служебного пользователя, если он был создан и больше не нужен.
NetWare Фундаментальный дебилизм для этой системы: для установки мало иметь NetWare, нужна ещё и Windows на клиенте. То есть надо найти такого клиента, войти с него в сервер под SUPERVISOR'ом и запустить install.exe. Дальше всё поставится традиционным образом, но запускаться не будет. Для запуска нужно сделать load iserver.nlm с командной строки или, для автоматического старта, из autoexec.ncf. И опять, как и в случае с Linux, Борланд плюёт на файловую защиту - все БД, создаваемые любыми пользователями, реально создаются с супервизорскими правами и в любом месте, где скажет клиент. Только вот NetWare - не Unix, и наложить защиту "руками" в нём никак не получается. Буду рад, если кто-нибудь придумает. А пока остаётся только сохранять бдительность.
Установка в основном происходит в каталог (если правильно помню) sys:interbas\, за исключением самого исполняемого модуля - sys:system\iserver.nlm. Чтобы грохнуть, нужно сначала выгрузить iserver, если он работает (unload iserver), а затем стереть всё ненужное. Windows 95 Существует несколько разновидностей InterBase, работающих под Windows, в том числе и 95. Мне попадался Local Server 4.0 и Interbase for Windows 4.2. Разница была в том, что первый поддерживал только локальные соединения, а второй признавал ещё и TCP/IP, правда, до 5 соединений одновременно. Плюс так же традиционная разница между 4.0 и 4.2. В остальном же InterBase for Windows - стандартный виндовский продукт со всеми общепринятыми глюками. То есть ставится в задаваемый пользователем каталог, но попутно кидает файлы в каталоги Windows и System, а так же залезает в несколько мест в реестре. Среди продуктов жизнедеятельности в файловой системе - interbas.ini, gds32.dll, драйвер ODBC (забыл, как называется файл). Основная проблема возникает тогда, когда надо поставить сервер на место предыдущей установки или поверх продуктов, которые содержат в себе клиент InterBase. Если попытаться поставить прямо "поверх", то часть файлов перепишется, и возникнет каша из версий, которая работать с большой вероятностью не будет. Единственный гарантированный и надёжный способ - грохнуть всю систему (каталог Windows) и переустановить всё, что нужно, включая InterBase. Для менее радикальной переустановки следует полностью вычистить старый InterBase. Насколько я себе представляю на данный момент, для этого нужно следующее: - Деинсталировать InterBase стандартным способом, сходив на Панель.
- Вытереть каталог, в который был установлен InterBase (он вполне может и выжить).
- Вытереть из каталогов Windows и System все прочие продукты жизнедеятельности InterBase.
- Пройтись по реестру, ища слово "rbas". Дело в том, что могут встретиться слова InterBase, INTERBAS, IntrBase, и им подобные. Разумеется, грохать нужно не всё подряд, а только те записи, которые действительно относятся к InterBase.
- На всякий пожарный случай перегрузиться.
- Проверить ещё раз, не осталось ли чего в каталогах или реестре.
- Установить InterBase заново.
Windows NT В целом InterBase for NT выглядит так же, как и for Windows 95. Отличие в том, что не урезана функциональность - поддерживаются все режимы и все сетевые протоколы. Поведение этого сервера и в установке, и в работе так же отличается не сильно. Таким образом, общий сценарий при переустановках тот же. Вот только одна большая загвоздка - попытка миграции с 5.0 на 4.2 не приводит к желаемому результату даже при полном выполнении вышеописанного сценария. То есть где-то в тайных дебрях системы остаются следы прежней установки и новая этого пережить не может. |