Сегодня я хочу поделиться нашим опытом в проведении аудита безопасности Drupal сайтов. В большей части это текст доклада нашего сотрудника Дмитрия Кочетова на DrupalCamp Krasnodar 2016. В основном, к нам обращаются за аудитом безопасности по 3-м причинам:
Docker очень популярная тема, давно интересуюсь контейнеризацией, и всё чаще в последнее время использую для своих проектов, а также для проектов в drupal-coder.ru.
Подробнее про саму технологию можно почитать тут:
https://docs.docker.com/engine/understanding-docker/
https://habrahabr.ru/company/infobox/blog/237405/
https://habrahabr.ru/post/253877/
Столкнулись с проблемой, у клиента есть относительно небольшой сайт, а места занимает достаточно много, что существенно сказывается на годовой стоимости резервного копирования. Возникло подозрение, что есть неиспользуемые файлы.
Эта статья как раз и посвящена поиску таких файлов на Drupal (и не только Drupal) сайте.
На днях появилась задача разобраться в проблеме обмена данными по протоколу XML-RPC между Drupal сайтами.
Для понимания проблемы, введем терминологию.
Клиент - Drupal сайт, запрашивающий информацию с Сервера
Сервер - Drupal сайт, отвечает на запросы с Клиента
Часто возникает ситуация, когда нужно быстро получить админский доступ к Drupal для проведения изменения, но мы не знаем пароля админа. В этой заметке в первой части рассмотрим, как можно выйти из этой ситуации, при помощи drush, т.е. мы заменим пароль админа, а потом после всех манипуляций вернем старый пароль админа на место. А во второй части - без drush.
Для начала посмотрим вывод команды:
drush sqlq "SELECT name, pass FROM users WHERE uid = 1;"
Вывод будет, например, таким:
Часто в работе приходится синхронизировать версию сайта для разработки с "продакшн" версией сайта. Это можно сделать как например описано в этом посте, но можно и одной командой с помощью Drush. Сегодня ма рассмотрим как можно быстро синхронизировать 2 Drupal сайта с помощью Drush.
В работе периодически сталкиваюсь с медленными Drupal сайтами, и тормоза очень часто вызваны медленным выполнением запросов к Mysql. Причины бывают разные, но зачастую медленное выполнение запросов вызвано тем, что при выполнении запроса MySQL вынуждено использовать временные таблицы на диске. Для этого используется каталог заданный в переменной tmpdir файла конфигурации my.cnf.
На мой взгляд, правильным решением в таких ситуациях является оптимизация базы данных (использование типов полей наиболее подходящих под содержимое, правильная настройка идексов, и построение корректных запросов к базе, учитывающих индексы в базе). Но также мы можем помочь MySQL если переместим эти временные таблицы в оперативную память (такое решение подходит для серверов с большим количеством оперативной памяти), что позволит более быстро выполнять операции связанные с использованием временных таблиц, за счет экономии на операциях записи и чтения с диска, так как всё будет делаться в оперативной памяти.
У нас в Drupal-coder.ru появился новый клиент на оптимизацию Drupal и дальнейшую поддержку.
Это большой региональный портал. У клиента сайт временами сильно тормозил и падал, хотя размещен у известного Drupal хостера. Из-за этих тормозов и невозможности получения root доступа у хостера мы решили перенести сайт на наш виртуальный сервер и разобраться в причинах торможения. Сервер настроили в следующем варианте Nginx + Apache + Mysql + PHP + Memcached + APC.
При очередном прочтении новостей в Google Reader увидел неплохую статью по быстрой настройке отправки email для Drupal сайтов. Автор пишет о настройке под Ubuntu, но способ вполне рабочий и на Debian. На мой взгляд быстрый и понятный способ, подходящий для большинства задач. Перевод статьи ниже.
Мы в drupal-coder.ru решили сделать выделенный сервер разработки, чтобы разработчики могли быстрее создавать drupal сайты, не тратя времени на прописывание virtual хостов, добавление записей в DNS, создание базы MySQL, установку Drupal. Также на этом сервере будет сдаваться работа заказчику.