Я хочу рассказать об одном нестандартном применении механизма сессий в PHP. Вспомнилось мне это в связи с позавчерашним постом Тормоза на тему, что опять в Даосе проблема с параллельным доступом к файлам - функция блокировки дала очередной сбой. И хотя Тормоз в комментах уже писал, что обкатывает исправленный алгоритм, успешно выдерживающий стресс-тест, я все же поделюсь своим решением. Сразу оговорюсь, все нижеизложенное было проделано just for fun и имеет свои недостатки. Зато и работает практически безотказно.

Перейду к технической части. По умолчанию механизм сессий в PHP использует хранилище данных в файлах - каждая сессия лежит в своем файле. При этом, чтобы обеспечить целостность данных используется нехитрый подход эксклюзивной блокировки доступа к файлу. Иными словами, в момент, когда мы делаем session_start(), движок PHP захватывает файл с требуемой сессией и отпускает ее только в момент явного вызова session_write_close() или завершения скрипта. И если в то время, пока мы работаем с сессией в рамках одного запроса, произойдет еще один запрос, использующий ту же сессию, то он заблокируется на session_start() до тех пор, пока первый не освободит файл. Обычно разные клиенты работают в разных сессиях и проблемы не возникает, однако (немного огрубляю) у одного и того же клиента в один момент времени исполняется только один запрос.

Реально проблема встает, когда во время выполнения некоторого длительного запроса (стримминг потока или long polling) надо обеспечить клиенту возможность посылать и другие запросы (ходить по страничкам) и вовремя получать ответы. Решают задаю обычно одним из трех путей:

1. Реализуют полностью свой механизм сессий.
2. Переопределяют обработчики операций с данными сессии во встроенном механизме (с помощью session_set_save_handler(), этим вариантом я в свое время и воспользовался).
3. Как можно раньше освобождают сессию с помощью session_write_close().

Но я отвлекся. В нашем случае мы не только не будем избавляться от этого, но наоборот будем использовать для реализации мьютекса: будем создавать сессию с заранее известным session_id, к примеру db_mutex, выполнять критические действия и закрывать сессию. Именно эту функциональность и реализует мой класс PHP_Mutex.

Надо признать, такой подход имеет ряд недостатков по сравнению с полноценными мьютексами:

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

Но если все условия удовлетворены (кстати, класс по мере возможности сам отслеживает потенциально проблемные ситуации и выдает ворнинги), то блокировка будет железной - разработчики PHP постарались, чтобы данные сессии были в безопасности в любой среде окружения :) Поэтому класс вполне сгодится в небольших скриптах типа Даоса, где сессии не очень нужны. Ну а в сложных системах можно прибегнуть и к тяжелой артиллерии вроде встроенных семафоров, у которых лишь один недостаток - по умолчанию они отключены.

Сам класс вы найдете во вложении, распространяется он свободно согласно лицензии New BSD License. Если кому пригодится - на здоровье :-)

С начала октября в моей жизни произошло одно существенное изменение - я стал сотрудником в компании Parallels. Пока лишь как интерн, но в условиях совмещения работы и учебы это оптимально, особенно при таком печальном расписании как в этом семестре :)

 Конечно, почивать на лаврах было бы глупо - уволят нафиг, но это в мои планы и не входит, поскольку наша команда будет работать над новым и интересным проектом, что вообще большая удача для меня. Удача потому, что большая часть программистского труда в крупных компаниях приходится на поддержку и развитие уже существующих проектов, со всеми их "исторически сложившимися" архитектурными костылями и задачами. Тут всегда найдутся темные куски кода, которые никто до конца не понимает или баги, бережно хранимые во имя обратной совместимости. А начало нового проекта - это шанс поучаствовать в гораздо более творческом процессе, поработать над архитектурой, исследовать технологии и не задумываться об обратной совместимости, до тех пор, пока проект не перестанет быть новым ;)

Что касается самой компании Parallels, то в зону моего внимания она попала достаточно давно, однако ее продукты у меня вызывали самые разные чувства. Два основных продукта, с которыми мне приходилось иметь дело - это Parallels Plesk Panel и OpenVZ.

С OpenVZ дело обстояло довольно просто, года два назад (офигеть, этому блогу уже два с половиной года и он мне еще не надоел) у меня случился пик интереса к технологиям серверной виртуализации и я естественно не мог обойти вниманием OpenVZ. Тогда я получил массу удовольствия, играясь с контейнерами и прикидывая, для чего оно мне могло бы сгодиться в хозяйстве, но так и не придумал и отложил в долгий ящик. Но теплые воспоминания остались. Позже я столкнулся с этой технологией уже как клиент и на данный момент обе мои VPS работают именно под этой технологией.

А вот с Plesk'ом у меня отношения сложились не так гладко. Года эдак три назад я работал с один человеком, у которого на VPS (точные параметры уже не вспомню, но довольно мощной) был установлен Plesk 7. Это было нечто. С одной стороны, он жрал почти половину памяти сервера даже в простое, держал много файловых дескрипторов и давал небольшую, но постоянную нагрузку на проц за счет постоянно запущенного собственного демона. В результате, сайт весьма основательно тормозил и падал с разными ошибками о нехватке ресурсов. Ну а интерфейс меня вообще приводил в тихое отчаянье: сделанный в стиле Windows XP он требовал для каждого осмысленного действия 3-4 перехода со страницы на страницу, каждый из которых происходил секунд по 10-15 еще и блокируя все действия на время загрузки страницы. То есть, если ты промахнулся и кликнул не туда, то ты не кликаешь тут же куда надо, а ждешь 10 секунд, пока загрузится ненужная тебе страница, потом еще 10 - пока вернешься назад и еще 10 - пока грузится та страница, куда ты хотел изначально. К счастью, клиент был вполне солидарен со мной и мы волевым решением избавились от панели управления вовсе, благо особой нужды в ней не было - на впс жил всего один сайт. С тех пор моими любимыми панелями стали Kloxo и ISPManager за легкость и эффективность.

Тем не менее, по работе мне пришлось познакомиться с бетой Plesk 10 и она произвела гораздо лучшее впечатление. Несмотря на то, что по потреблению ресурсов она все еще мало пригодна для VPS, интерфейс стал на порядки отзывчивее. Так что можно считать, что Plesk реабилитировался в моих глазах.

Дублирую сюда мой пост на Хабре:

GRUB, безусловно, является самым продвинутым загрузчиком на сегодняшний день, и за это любим админами и разработчиками по всему миру. Его функционал настолько широк, что он практически монополизировал рынок загрузчиков в мире *NIX, а некоторые вообще говорили, что GRUB2 — это скорее маленькая операционная система, чем просто загрузчик. Эдакий швейцарский нож в мире загрузчиков.

Но в этот раз я хочу обратить внимание на то, что с помощью швейцарского ножа можно не только открывать консервы, но и вырезать неприличные слова на парте.

Сценарий 1: загружаемся со внешнего носителя

Ситуация, когда в BIOS заблокирована загрузка со внешних носителей, — отнюдь не редкость. Делается ли это из соображений безопасности или иных причин не так уж и важно. Важно то, что GRUB может помощь нам преодолеть этот барьер. Ниже описана последовательность действий, которая позволит нам загрузиться с флешки.

1. Изготавливаем загрузочную флешку любым способом, например, с помощью unetbootin.
2. Вставляем флешку и включаем компьютер.
3. Дожидаемся появления экрана grub (иногда для того, чтобы успеть его поймать, надо держать Shift).
4. Перед нами появляется список вариантов загрузки.
5. Нажимаем c и входим в интерактивный режим.
6. Теперь требуется указать носитель, с которого будем грузиться. Обычно (hd0) — это родной жесткий диск компьютера, а флешка становится (hd1). Выяснить, как назовется флешка в вашем случае, нетрудно просто опытным путем.
   Так или иначе, вводим: root (hd1) для GRUB Legacy или set root=(hd1) для GRUB2
7. Просим передать управление загрузчику на указанном диске: chainloader +1
8. Загружаемся! boot

Если вы все сделали правильно, то в результате вы успешно загрузитесь со своей флешки, несмотря на запрет в биосе. Опытным путем мне удалось выяснить, что метод не работает если ваша материнка не умеет грузиться с usb или не опрашивает устройства при каждой загрузке (как, например, на моем eee PC при включенном Boot Booster).

Лирическое отступление: этот метод мне удалось опробовать в одном из терминальных классов нашего университета, где на компах стояли в дуалбуте винда с линуксом. Прелесть того случая в том, что факультетский сервер экспортировал /home по NFS и та терминалка была занесена в разрешенные подсети. В результате, мне удалось прочитать домашние каталоги пользователей того сервера и уйти так никем и незамеченным.

Сценарий 2: получаем консоль root'a

Опять-таки, ситуация, когда пароль рута не сообщают конечным пользователям компьютера, ни у кого удивления не вызывает. Однако все тот же GRUB поможет нам это досадное ограничение обойти. В отличие от предыдущего способа, удобного для доступа в духе «незаметно пришел, скопировал и ушел, не наследив», этот способ удобнее для внесения нужных нам изменений в установленную систему. Кроме того, для этого нам уже не нужны никакие флешки.

1. Аналогично, добираемся до списка вариантов загрузки.
2. Выбираем нужный нам вариант.
3. Входим в режим редактирования. Здесь есть небольшие отличия между GRUB Legacy и GRUB2. В GRUB2 после нажатия клавиши e мы сразу попадаем в режим редактирования, а в GRUB Legacy нужно нажать e первый раз, выбрать строку для редактирования и еще раз нажать e.
4. Выбираем строку, которая начинается со слова linux или kernel.
5. Удаляем из нее слова quiet и splash, если они есть, и дописываем в конец single init=/bin/bash
6. Если у нас GRUB2, то сразу жмем Ctrl+X, а если GRUB Legacy — Esc и потом b

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

Защита?

И GRUB2, и GRUB Legacy предоставляют возможность ограничить доступ к интерактивному режиму и редактированию с помощью директивы password. Подробности описаны в руководстве по GRUB2 и GRUB Legacy. В обоих случаях манипуляции весьма просты и не требуют много времени.

Баян!

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

Пришло время опубликовать первый из проектов, которые я упомянал в позапрошлом посте. Позвольте представить вам мой новый сайт-визитку: Nevkontakte.ME.

Мысль о том, что неплохо было бы сделать небольшой сайт-визитку проскальзывала у меня уже довольно давно, однако делать еще один тупой трехстраничник в духе "Главная, обо мне, контакты" было неинтересно. И тут я вспомнил об одном из старых постов Тормоза, в котором он предлагал концепт Cuby CMS — движка для микросайтов в виде, как это ни странно, куба. Однако у Тормоза дело не пошло дальше концепта, а у меня как раз была нужда в чем-то оригинальном и в добавок желание поупражняться в JavaScript-fu.

Взяв за основу идею Тормоза, я добавил анимацию перехода между сторонами с помощью CSS3 2D Transforms (по началу хотел для большей реалистичности юзать 3D Transforms, однако его пока поддерживают только nightly-билы вебкита), немного плюшек для более прозрачной навигации и удобную AJAX-админку.

Однако, поскольку я при этом юзал достаточно свежие технологии, в конце пришлось озаботиться совместимостью со старыми браузерами, в результате чего был порожден упрошенный режим без анимаций для динозавров. Кроме того, для полноты счастья был сделан и режил для работы без JavaScript вовсе.

Вживую все это вы можете повертеть на Nevkontakte.ME, а админку посмотреть на скриншоте:

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

Сегодня, заглянув очередной раз в RSS-ридер и бегло проглядев список новых постов, понял, что больше половины блогов, на которые я подписан, отдают в RSS лишь жалкие огрызки постов и меня это жутко удручает. В частности, читать такие посты мне уже не хочется и я зачастую их пропускаю практически машинально - разве что заголовок зацепит, но это бывает не часто. И в то же время я отдаю себе отчет в том, что будь пост целиком в моем ридере - я бы его прочитал, хотя бы по диагонали.

Почему же такая практика стала популярной? Я сходу могу назвать такие причины:

1. Защита от автоматического воровства контента (по-видимому, самая главная).
2. Стимуляция пользователя лишний раз зайти на блог.
3. Желание защитить пользователя от "попадания на трафик" на случай, если вдруг получится большой пост с кучей картинок.
4. Все так делают.

Все эти аргументы кажутся мне довольно неубедительными, и вот почему:

1. Современные парсеры-грабберы достаточно умны, чтобы пройти по ссылке из ленты на сайт и стащить полный пост.
2. На самом деле тут все, как мне кажется, наоборот: пользователь как правило или ленив или спешит, поэтому он не будет утруждать себя чтением огрызка и кликом, если тот его не заинтересует с первого взгляда. А заинтересовать не так-то просто. Кроме того, все мы знаем о собственном любопытстве и что если начнем читать - наверняка захочется прочитать все, а кликать лень, лучше не напрягаться и не начинать читать вовсе. В результате блоггер не только не увеличивает посещаемость блога, но и "теряет" часть подписчиков из-за того, что они не читают его посты целиком.
3. Признайтесь честно, вы не так уж и часто пишете такие посты. И если вдруг случится, что напишете, то вручную поставить кат совсем недолго.
4. Ну это вообще просто стадный эффект.

Помимо этого я вижу еще как минимум один минуса:

1. Этот актуален для многих блоггеров, а именно - тех, кто сидит на Вордпрессе. ВП имеет дурное свойство при автоматической генерации тизера для RSS срезать половину форматирования, которое пересекает границу отсечения и в результате выглядит этот тизер ну совсем непривлекательно. Да и обрыв на полуслове тоже не добавляет изящества.
2. Здесь затронуты мобильные пользователи вроде меня - те, кому удобно закачать обновления ленты дома, а потом спокойно читать в том же транспорте, не тратя деньги на мобильный трафик, цены которого всегда казались мне сильно завышенными.

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

Вообще, самое грамотное решение этой проблемы я видел у vitashok'a: у него есть два фида: полный и урезанный. Рекомендую все брать с него пример ;)

А что же делать читателям до тех пор, пока мир не изменится к лучшему? Например, пользоваться сервисами вроде этого.  Фиды блогов с не слишком дурацкой версткой от вполне успешно превращает в полнотекстовые, но, к сожалению, бывают и сбои.

PS. В RSS я полные посты отдаю уже давно, а с этого момента и на главной блога посты тоже будут отображаться целиком.