Менеджер обновлений в Друпале 7: что сделано и что еще предстоит сделать.

Это перевод статьи http://3281d.com/2009/11/03/d7-update-manager

Раньше в этом блоге было довольно тихо, но не из-за того, что мы ничего не делаем, а напротив, я был так занят, что мне банально не хватало свободного времени. Чтобы наконец нарушить тишину, я начну с отчета о состоянии Менеджера обновлений — теперь друпал может (безопасно) обновляться, при выходе новой версии. Эта возможность устраняет главную причину головной боли основной части Друпал сообщества и помогает поддерживать большинство сайтов, основанных на Друпале в стабильном и безопасном состоянии. Однако, требуется обработать еще множество острых граней до выхода Друпала 7 и помощь нам сейчас крайне необходима, чтобы успеть дать жизнь этой возможности до дедлайна.

В этом обзоре вы найдете:

  • предыстория
  • принцип работы
  • как отключить Менеджер, если он вам не нужен
  • как отключить Менеджер, если он вам не нужен.

Предыстория:

Идея создания модуля вынашивалась много месяцев, при содействии разных людей и реализовывается только благодаря героическим усилиям Якоба Синга (Jacob Singh), который написал ядро модуля. Якоб исправил бесчисленное количество ошибок ядра, несовершенств архитектуры и даже нечеркал заметку last minute storm. Однако, энтузиазм Якоба начал увядать, помощь, которую он просил, он так и не получал, а код казался еще сырым. Все это тормозило проект и размывало дату его окончания. Именно в этот момент я полностью включился в проект.

Как разработчик модуля «Статус Обновлений» для Друпала 6 (и вспомогательного модуля «Статус Обновлений» Друпала 5) и как член команды Безопасности Друпала, которая была заинтересована в сайтах, обновляющихся до свежих и безопасных релизов я хотел быть уверенным, что эта функция все-таки появится и все будет сделано правильно. Я изредка просматривал предыдущие выпуски модуля, находил кое-какие баги, но не принимал непосредственного участия в разработке. 11 октября Якоб бросил разработку и ее продолжил я.

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

Я закончил реорганизацию и переписывание большей части модуля в течение последующих 4-х дней с результатом, которым могу гордиться. Под громкие фанфары (хотя я не состою в твиттере, утверждают, что «твит-сообщество сошло с ума», а я был практически завален поздравлениями в IRC) webchick успел сообщить об этом событии разработчикам Друпала 7 в обед, 15 октября, в день дедлайна. Фух!

Принцип действия:

Модуль, ранее известный, как «статус обновлений»(update status), в Друпале 7 теперь называется «Менеджер обновлений» (Update manager). Таблица «Доступные обновления», которую вы все знаете и любите (а может и ненавидите) осталась, но появилось две новые страницы: «обновление сайта» и «установка новых модулей и тем».

Обновление существующих модулей и тем:

Для обновления уже имеющихся модулей теперь существуют специальная страничка, где выводится список рекомендуемых апдейтов с чекбоксами (см. скиншот выше). После того, как вы выберете, что обновить или установить Менеджер обновлений скачает необходимые пакеты, поместит их во временную папку и проверит их. Если все хорошо вы увидите:

После того, как вы подтвердите готовность к обновлению, вы будете перенаправлены на скрипт authorize.php, где вы можете выбрать нужные вам обновления. (см. далее)

Установка новых модулей и тем:

Другая возможность Менеджера обновлений — установка новых модулей и тем:

После того, как вы загрузите архив или введете URL, Менеджер обновлений скачает, распакует и проверит файлы, если все хорошо, перенаправит вас на скрипт authorize.php для установки новых модулей или тем.

Скирипт authorize.php:

Скрипт authorize.php лежит в корневой директории (вместе с index.php, update.php и т.д.) и играет наиважнейшую роль в работе Менеджера обновлений. При первом обращении к скрипту, он спросит у вас необходимую информацию для соединения с вашим сайтом (через SSH или FTP). Это требуется для того, чтобы скрипт удостоверился в том, что вы являетесь владельцем сайта, а не владельцем вебсервера. При определенной настройке, управлять скриптом может и владелец сервера. В этом случае скрипт не будет спрашивать деталей соединения и просто запишет файлы в папку. При этом ваш пароль нигде не хранится, а используется только во время записи файлов. Для сравнения в OSX для запуска обновления програмного обеспечения обычно требуется ввести пароль Администратора. Примерно по такому же принципу работает модуль обновления Друпала.

Другая важная деталь, касаемая authorize.php это то, что он runs at a very low Drupal bootstrap level что означает, что загружена лишь малая доля функциональности ядра и никакие дополнительные модули не загружаются вовсе. В этом случае, если новый релиз работает не правильно, менеджер обновления все еще может взаимодействовать с ним, и поможет вам восстановиться после неудачного обновления. Это делает использование скрипта более безопасным, так как становится практически невозможным провести скриптованную атаку, чтобы завладеть вашими FTP/SSH реквизитами. После того, как вы разрешили Менеджеру обновлений проапдейтить ваш сайт он соединяется с файловой системой и выдает страницу, где подробно описан отчет о состоянии.

Как отключить модуль:

Модуль может оказаться очень полезным для многих владельцев простого сайта на выделенном хостинге, но я бы не рекомендовал использовать его, владельцам «настоящего» сайта с серверами, отведенными под разработку, тестирование и развертку готового продукта. Также он вам не понадобится если вы управляете сайтом через Aegir или используете drush. Для подобных случаев существует простой способ полного отключения менеджера обновлений: в файле default.settings.php нужно раскомментить эту строку:

$conf['allow_authorize_operations'] = FALSE;

При значении False отчет об обновлениях (который я до сих пор называю «статус обновлений») все еще будет активен, но ни одна из новых функциональностей не будет задействована. Новые страницы Менеджера обновлений не будут отображаться, а скрипт authorize.php будет не активен. Если вы попытаетесь посетить любую из дополнительных страниц Менеджера, даже будучи залогиненым под супер пользователем (ID пользователя – 1), в доступе вам будет отказано.

Blog categories: DrupalПереводы