Каким должен быть идеальный виртуальный хостинг (в том числе и для Drupal 7)

Как сказал кто-то из великих:

Идеала достичь невозможно, но стремиться к этому нужно.

Поэтому сегодня я пофантазирую о том, каким должен быть идеальный виртуальный хостинг.

Фантазировать буду, безусловно, со своей колокольни: у нас в агентстве для своих нужд виртуальный хостинг уже давно не используется, мы сначала перешли на VDS, а потом и на выделенные железные серверы. Соответственно, для собственных и регулярно поддерживаемых клиентских проектов — вопрос с хостингом решён так, как нам нравится и кажется правильным (dedicated). Но к нам довольно часто обращаются за разовой поддержкой клиенты со стороны. И тогда мы отправляемся покорять чужие виртуальные хостинги от самых разных провайдеров. Подобные визиты часто оканчиваются печалью.

На этот пост меня спровоцировал мой любимый трижды лучший сотрудник месяца компании Мастерхост — Иван (знакомьтесь, фоловьте):

Речь перед этим твитом зашла о лютых ограничениях на «Мастерхосте», с которыми мы недавно столкнулись, пытаясь завести на упомянутом хостинге сайт, построенный на базе Drupal 7. Вообще, «Мастерхост» — это лишь яркий пример и достойный повод, странных хостеров — хватает и без них. Далее перечислю наиболее типовые странности хостеров, мешающие жить и работать. Читайте далее…

Самый изящный PHP-shell из попадавшихся мне в последнее время

Что-то мне в последнее время везёт на инфицированные сайты (наверное, помните про вирус в .htaccess). Вот и ещё один клиент пришёл в наше агентство взломанным. Его похоже бахнули через подбор FTP-пароля (он у него лишь из цифр состоял), но, кстати, и этот взломанный сайт тоже крутился (и пока крутится) под управлением Joomla 🙂 В общем, в подарок клиенту закинули один из самых лаконичных PHP-шеллов, который только можно себе представить. Не удержусь от того, чтобы процитировать «зловредный» код… Немного знающие PHP далее оценят лаконичность злого гения…

Резервное копирование сайта с удалённого сервера по FTP, включая автоматическое создание дампа базы данных

Дано: есть у вас сайт на удалённом сервере, доступ к которому предоставлен только по FTP (это к файлам, а к базе данных вам дали логин/пароль и ссылку на phpMyAdmin). Планировщик cron на удалённом сервере вам использовать тоже нельзя (и к нему нет доступа). Задача: организовать регулярное резервное копирования файлов и базы данных на ваш компьютер или сервер.

Проблемы бы не существовало, если б копировать надо было только файлы. Но нам как-то надо регулярно получать и дампы базы. Это притом, что удалённых команд через SSH мы на сервере с сайтом выполнять не можем.

Я сначала опешил, но решение родилось вполне тривиальное — дампить базу PHP-скриптом, который будет запускаться нашим скриптом резервного копирования с нашего сервера перед сливом файлов. Далее представлено работающее решение задачи, состоящее из двух скриптов…

Злой вирус в .htaccess перенаправлял посетителей с поисковиков на посторонние рекламные сайты

Простите за заголовок в стиле жёлтой прессы и канала «НТВ», но сегодня наша команда столкнулся с интересной проблемой: при переходах по объявлениям Яндекс.Директа у одного из наших клиентов наблюдалась странная ситуация — пользователь при клике по объявлению в итоге попадал не на целевой сайт, а на одну из мутных площадок, где предлагают оставить на память злым ботам свой номер телефона (и потом разориться на платных sms). При заходе на целевой сайт путём ввода домена «руками» или по ссылкам на сайт из почты, скайпа, закладок — всё было ок.

Природа площадок сразу же намекнула на то, что виной всему происходящему — некий вирус (а не Яндекс). Читать далее о том, как я лечил сайт от вируса…

Кодировки MySQL и бинарные данные в полях типа BLOB и ТEXT — проблема из-за которой я не спал целую ночь

Идейно нелюбимые мной «Битрикс» и Joomla намного лучше любой студийной CMS. Исключение наступает лишь в тот момент, когда студийная CMS становится популярным opensource-продуктом, в котором ковыряются разные люди никак не связанные со студией. Потому что только в этом случае вырастает сообщество, проходящее строем по всем типовым граблям, набивающее шишки и заполняющее интернет ответами на типовые вопросы и рассказами о типовых проблемах. Вот таким публично испробованным продуктом уже можно смело пользоваться. Иначе — вечная зависимость от студии.

Лирическое вступление посвящается студийной CMS — S.Builder 3.7, чья админка работает только в Internet Explorer. На форуме разработчики на многие вопросы отвечают примерно так: «пришлите нам FTP-доступ к вашему хосту, мы проблему поправим». То есть пользы от форума не сильно больше, чем от закрытой тикет-системы. При переносе сайта с одного хоста на другой я упёрся лбом в проблему с кодировками. Увидев на странице часть русского текста и часть «кракозябров» привычно вздохнул: проблема типовая, сейчас втисну куда-нибудь запрос SET NAMES cp1251 и всё заработает. Но, не тут-то было. Читать далее о том, в чём же состояла проблема и как она разрешилась…