…или как исправить зеленую черепашку в VirtualBox :)

Наверное многим известна проблема запуска виртуальной машины под Win11, тем что не всегда получается использовать аппаратную функцию VT-x/AMD-V. Как правило корень этой проблемы в самой Windows 11, а именно в том что она использует эту функцию самостоятельно, соответственно заблокировав её для других.

Без VT-x/AMD-V VirtualBox переключается в режим работы через Native API (NEM), а Native API — это жуткие тормоза из-за лишней прослойки. Причины гуглятся вроде очень быстро, но, помимо очевидных причин есть и неочевидные, об этом под катом.

Чек-лист диагностики

Быстрый чек-лист для диагностики (см. подробнее далее):

• BIOS — включена ли VT-x/AMD-V физически.
• bcdedit /enum | findstr hypervisorlaunchtype — должно быть Off.
• Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All, VirtualMachinePlatform, HypervisorPlatform — все должны быть Disabled.
• Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard — VirtualizationBasedSecurityStatus должен быть 0.
• Если статус не 0 — открыть msinfo32, посмотреть «Запущенные службы» в разделе VBS, и отключить именно ту конкретную службу (Credential Guard / Memory Integrity (HVCI) / System Guard) по инструкциям ниже.
• Проверить лог самой ВМ (VBox.log) на строку Using: VT-x (успех) против Falling back to NEM (всё ещё заблокировано).

То, что делаем в первую очередь

Базовые вещи, которые нужно сделать сразу и которые легко гуглятся.

Включить виртуализацию в BIOS

Самый первый и самый очевидный шаг — проверить BIOS. Если выключено — включить :)

Отключаем компоненты виртуализации Windows

Давайте начнём с того, что все рекомендуют сделать в первую очередь: жмём Win+R, вводим optionalfeatures и отключаем всю виртуализацию:

• Hyper-V и все подкомпоненты
• Платформа виртуальной машины (Virtual Machine Platform)
• Платформа гипервизора Windows (Windows Hypervisor Platform)
• Песочница Windows (Windows Sandbox)

Отключение гипервизора

В консоли с админ-правами выполняем bcdedit /set hypervisorlaunchtype off и отключаем запуск защищённых сред bcdedit /set vsmlaunchtype off.

Изоляция ядра / Core Isolation

Открыть Параметры (Win+I) → Конфиденциальность и безопасность → Безопасность Windows → Безопасность устройства. Перейти в «Сведения об изоляции ядра» и перевести ползунок «Целостность памяти» в положение «Выкл».

А теперь что помогло мне

Так, а теперь что делать, если перечисленное выше не помогло. (Естественно, не забываем перезагружать компьютер после каждого пункта.)

Диагностика через msinfo32

Открываем msinfo32 и смотрим на строку «Безопасность на основе виртуализации». Если там значится «Выполнение» — значит, что-то из служб VBS всё ещё держит VT-x занятым. Смотрим строку «Запущенные службы» чуть ниже — она укажет, что именно нужно отключать: Credential Guard, Memory Integrity (HVCI) или System Guard Secure Launch.

Credential Guard

Если в запущенных службах значится Credential Guard — отключаем его через редактор реестра или через консоль:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\LSA" -Name "LsaCfgFlags" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -Value 0 -Type DWord -ErrorAction SilentlyContinue

Некоторые мануалы после этого действия рекомендуют делать две перезагрузки подряд (что-то в духе: в первый раз применяется политика, а во второй раз отключается эта защита, но я не вникал).

Memory Integrity (HVCI)

Если тумблер «Целостность памяти» в Параметрах не отключается или Windows включает его обратно, есть вариант через реестр:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -Value 0 -Type DWord

System Guard Secure Launch

Похоже на Credential Guard — тоже VBS-служба:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard" -Name "Enabled" -Value 0 -ErrorAction SilentlyContinue

Групповая политика

gpedit.msc → Конфигурация компьютера → Административные шаблоны → Система → Device Guard → отключить политику «Включить средства безопасности на основе виртуализации».

Актуально в первую очередь для доменных/корпоративных машин — если политика управляется централизованно, локальное отключение может быть переопределено доменной GPO, и потребуется обращение к ИТ-администратору.

The post VirtualBox и Windows 11 и Native API first appeared on IntSystem.org.

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

В целом, конечно, забавно и самому прочитать ту ерунду которую ты писал будучи на 10 лет моложе, но это был тоже опыт, да и блог этот был создан чтобы в первую очередь делиться чем то, что тебе самому кажется интересным. Так что я себя ни в коем разе не осуждаю, а наоборот горжусь :)

The post И да, этот блог еще жив :) first appeared on IntSystem.org.

Прошлая статья подвела нас к тому, что основа ассиметричного шифрования — это публичный и приватный ключи, которыми осуществляется шифрование и дешифрование сообщений. Алгоритм в двух словах выглядит вот так:

1. мы берем публичный ключ того кому хотим отправить сообщение;
2. шифруем сообщение с помощью ключа;
3. передаем сообщение по открытому каналу;
4. адресат расшифровывает сообщение своим приватным ключом.

Представим что Боб получил зашифрованное сообщение от Алисы. Но от Алисы ли? Да, в конце письма может быть написано «С любовью, Алиса», но откуда нам знать, что это не подлая Ева представляется чужим именем? Но впрочем с любовными письмами это может показаться не такой большой проблемой, не так ли? Тогда представьте себе более серьезную организацию — банк. Банк у которого есть множество филиалов по всему миру с головным офисом, который выполняет и отвечает за все банковские операции по переводу денег. Откуда головному офису знать, что пришедшее письмо с просьбой перевести миллиард долларов на некий счет, пришло действительно от филиала как написано в письме, а не от злоумышленника, который хочет перевести эти деньги на свой счет?

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

Подпись документа

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

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

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

Впрочем для того чтобы удостоверить отправителя совсем не обязательно шифровать текст целиком. Можно, например, зашифровать приватным ключом хеш от исходного текста и полученную строку передавать получателю вместе с текстом. На другом конце получатель расшифровывает подпись публичным ключом, и сравнивает ее с хешем полученного документа. Вот так выглядит генерация подписи:

А вот так проверка этой подписи на стороне получателя:

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

Передача конфиденциального письма

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

Алиса шифрует сообщение своим приватным ключом; шифрует еще раз публичным ключом Боба; передает сообщение по открытому каналу; Боб расшифровывает шифротекст своим приватным ключом; расшифровывает еще раз публичным ключом Алисы.

Вообразите себе сообщение, окруженное хрупкой внутренней оболочкой, которая представляет собой шифрование, выполненное с помощью приватного ключа Алисы (подписи), и прочную наружную оболочку, представляющую шифрование с использованием публичного ключа Боба. Получающийся шифротекст может быть расшифрован только Бобом, потому что только он имеет доступ к приватному ключу, необходимому для того, чтобы разбить эту прочную наружную оболочку. Расшифровав наружную оболочку, Боб затем сможет легко расшифровать с помощью публичного ключа Алисы и внутреннюю оболочку; эта внутренняя оболочка служит не для того, чтобы защитить сообщение, она удостоверяет, что данное сообщение пришло от Алисы, а не от какого-нибудь мошенника.

Заключение

В целом это все что стоит знать о цифровой подписи. А также достаточно для того чтобы понять дальнейший материал, так как он будет связан.

Я решил публиковать отдельные статьи о определенных аспектах криптографии, вместо целой и связанной статьи. Почему отдельные? Потому что написание огромной статьи я постоянно откладывал на потом. А так глядишь — по чуть-чуть и напишу все то что хотел :)

В дальнейшем ждите статей на тему MiTM и сертификатов, проблеме глобального наблюдателя и о том почему конфиденциальности нет в принципе :)

The post Цифровая подпись first appeared on IntSystem.org.

Вообще что такое Let’s Encrypt? Это центр сертификации который выдает бесплатные HTTPS сертификаты. Ну и немножко википедии:

Проект Let’s Encrypt создан для того, чтобы большая часть интернет-сайтов смогла перейти к шифрованным подключениям (HTTPS). В отличие от коммерческих центров сертификации, в данном проекте не требуется оплата, переконфигурация веб-серверов, использование электронной почты, обработка просроченных сертификатов, что делает процесс установки и настройки TLS-шифрования значительно более простым. Например, на типичном веб-сервере на базе Linux, требуется исполнить две команды, которые настроят HTTPS шифрование, получат и установят сертификат примерно за 20-30 секунд.

У сервиса есть несколько ограничений которые немного печалят, сертификат выдается сроком всего на 3 месяца, отсутствуют WildCard сертификаты. Первое ограничение объясняют тем что мол в случае компрометации, сертификат, выданный на 3 месяца, нанесет вреда меньше, чем сертификат выданный на год.

Теория заговора: хотя мне кажется все эти ограничения созданы искусственно с другой целью — оставить остальные центры сертификации на плаву. Кому то будет лень настраивать cron на перевыпуск сертификата, или же перевыпускать его вручную каждые три месяца. Кому то лень получать сертификаты на все поддомены. А так Let’s Encypt занимает свою нишу среди гиков, которым такие вещи только нравятся.

Как установить Let’s Encypt?

Для этого существует специальный одноименный клиент созданный этой же организацией:

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

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

 ./letsencrypt-auto certonly --webroot -w [path to webroot dir] -d [domain]

В моем случае это выглядит вот так:

 ./letsencrypt-auto certonly --webroot -w /var/www/intsystem.org/public_html/ -d intsystem.org -d www.intsystem.org

После чего будет создан каталог /etc/letsencrypt/live/intsystem.org/ с символическими ссылками на сертификаты и ключ:

lrwxrwxrwx 1 root root  cert.pem -> ../../archive/intsystem.org/cert1.pem
lrwxrwxrwx 1 root root  chain.pem -> ../../archive/intsystem.org/chain1.pem
lrwxrwxrwx 1 root root  fullchain.pem -> ../../archive/intsystem.org/fullchain1.pem
lrwxrwxrwx 1 root root  privkey.pem -> ../../archive/intsystem.org/privkey1.pem

Теперь путь к ним осталось прописать в конфиг Nginx

ssl_certificate "/etc/letsencrypt/live/intsystem.org/fullchain.pem";
ssl_certificate_key "/etc/letsencrypt/live/intsystem.org/privkey.pem";
ssl_trusted_certificate "/etc/letsencrypt/live/intsystem.org/chain.pem"; #Если используете OCSP

и рестартуем Nginx.

Как обновить сертификат?

Особого умения тут тоже не надо, используем ту же самую команду, но с параметром --renew-by-default:

./letsencrypt-auto certonly --renew-by-default --webroot -w [path to webroot dir] -d [domain]

В моем случае:

./letsencrypt-auto certonly --renew-by-default --webroot -w /var/www/intsystem.org/public_html/ -d intsystem.org -d www.intsystem.org

После выпуска и получения новых сертификатов, должны автоматически обновится символические ссылки на них:

lrwxrwxrwx 1 root root  cert.pem -> ../../archive/intsystem.org/cert2.pem
lrwxrwxrwx 1 root root  chain.pem -> ../../archive/intsystem.org/chain2.pem
lrwxrwxrwx 1 root root  fullchain.pem -> ../../archive/intsystem.org/fullchain2.pem
lrwxrwxrwx 1 root root  privkey.pem -> ../../archive/intsystem.org/privkey2.pem

и рестарт Nginx (reload).

Как обновлять сертификат Let’s Encypt автоматически?

Для этого можно добавить следующие комманды в крон на каждые два месяца:

[path]/letsencrypt-auto certonly --renew-by-default --webroot -w [path to webroot dir] -d [domain]
service nginx reload

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

Итог

The post Поставил сертификат Let’sEncrypt first appeared on IntSystem.org.

На всякий случай попробую объяснить. В некоторых ситуациях инъекция происходит в запросе который непосредственно не выводит никаких данных на страницу, либо же вообще никак не влияет на вывод. И если в первом случае данные из базы можно извлечь относительно просто, используя IF, косвенно влияя на вывод страницы, и тем самым прибегнув к бинарному поиску. То вот во втором случае — все очень грустно, бинарный поиск, как правило, основывался на конструкции SLEEP и замере времени ответа, что давало огромные задержки на вывод данных через эту инъекцию.

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

Duplicate entry

Наверное это один из самых популярных векторов атаки. Его предложил некто Qwazar еще в лохматые года. Выглядит он вот так:

SELECT COUNT(*) FROM (SELECT 1 UNION SELECT 2 UNION SELECT 3)x GROUP BY CONCAT(MID([YOUR_QUERY], 1, 63), FLOOR(RAND(0)*2))

Потом этот способ дорабатывали все кому не лень (забегу немного вперед, в т.ч. и я), в итоге самый оптимальный и короткий запрос на сегодняшний день выглядит вот так:

SELECT COUNT(*) FROM (SELECT 1 UNION SELECT 2)x GROUP BY MID([YOUR_QUERY], FLOOR(RAND(33)*2), 64)

Так например, такой запрос:

SELECT COUNT(*) FROM (SELECT 1 UNION SELECT 2)x GROUP BY MID(VERSION(), FLOOR(RAND(33)*2), 64)

Выведет вот такую вот ошибку:
Duplicate entry '5.5.25-log' for key 'group_key'
Как видно — мы смогли передать в текст ошибки нужные нам данные, что существенно ускорит нашу атаку в дальнейшем. Ограничение — за один запрос выведется не более 64 символов.

[su_spoiler title=»Почему это работает» style=»fancy» anchor=»whyItWork»]

Почему это работает?

Скажу честно, ради этого я и писал эту статью)

Максимально упростим запрос и сделаем его нагляднее:

SELECT COUNT(*) FROM (SELECT 1 UNION SELECT 2 UNION SELECT 3)x GROUP BY FLOOR(RAND()*2)

Рассмотрим запрос внимательно. В нем 3 строки группируются по полю RAND (при этом FLOOR(RAND()*2) может вернуть либо 1 либо 0). Для этого MySQL создает промежуточную, временную таблицу temporary table, и, проходя каждую строку, записывает в нее результат вычислений. После чего на основе этой таблицы строится результат самого запроса. Для нашего случая эта таблица должна бы выглядеть как то так:

group_key|count
---------+--------
 1       | 2
 0       | 1

group_key — как уже понятно — является результатом вычисления FLOOR(RAND()*2) для каждой строки. При этом group_key является уникальным индексом в этой таблице, т.е. два значения group_key равным например «1» — недопустимая ситуация.

То как организуется заполнение этой временной таблицы, выглядит приблизительно так в виде псевдокода:

если (ключ [FLOOR(RAND()*2)] существует в temporary_table ) {
  //увеличить счетчик для данного group_key
  выполнить("UPDATE `temporary_table` SET `count` = `count` + 1 WHERE `group_key` = FLOOR(RAND()*2)")
} иначе {
  //добавить новую строку
  выполнить("INSERT INTO `temporary_table` (`group_key`, `count`) VALUES (FLOOR(RAND()*2)), 1")
}

(на самом деле немного не так, возможно связано с какими-то дополнительными оптимизациями, надо лезть в исходники, мне лень)

Обратите внимание! В результате этих манипуляций на каждую одну строку два раза вызывается RAND.

Теперь представим на секунду что FLOOR(RAND()*2)) выдаст следующий порядок значений на каждый вызов 1 1 1 1 0 1, то временная таблица будет заполнятся следующим образом:

// '1' еще не существует в `temporary_table`
INSERT INTO `temporary_table` (`group_key`, `count`) VALUES (1, 1);

// '1' уже существует в `temporary_table`, увеличиваем счетчик
UPDATE `temporary_table` SET `count` = `count` + 1 WHERE `group_key` = 1;

// '0' еще не существует в `temporary_table`
INSERT INTO `temporary_table` (`group_key`, `count`) VALUES (1, 1); 
//Обратите внимание! Было проверено наличие '0', а вставляется '1'

В итоге на последнем запросе мы видим ошибку «Duplicate entry«, так как он пытается вставить во временную таблицу второе уже существующее значение уникального индекса. Т.е. MySQL проверил что «group_key = 0» еще нет в таблице, и решил добавить его, но при этом при добавлении вызывал еще раз RAND, которое вернуло другое значение «1«, которое уже существует в таблице.

Вернемся к оригинальному запросу (допустим мы хотим получить VERSION()):

SELECT COUNT(*) FROM (SELECT 1 UNION SELECT 2 UNION SELECT 3)x GROUP BY CONCAT(MID((VERSION()), 1, 63), FLOOR(RAND(0)*2))

Для RAND здесь указан конкретный seed равный 0 (RAND(0) <----- где "0" это seed). seed — это начальное значение с помощью которого генерируются остальные случайные числа. Т.е. для всех одинаковых реализаций генератора случайных чисел с одинаковым заданным seed должен выдаваться одинаковый набор чисел. В случае MySQL гарантируется что для одинаковых версий будет сгенерирован одинаковый набор чисел.

При выполнении этого запроса group_key будет выглядеть как то так 5.5.251 и заполнятся временная таблица будет следующим образом:

// '5.5.251' еще не существует в `temporary_table`
INSERT INTO `temporary_table` (`group_key`, `count`) VALUES ('5.5.251', 1);

// '5.5.251' уже существует в `temporary_table`, увеличиваем счетчик
UPDATE `temporary_table` SET `count` = `count` + 1 WHERE `group_key` = '5.5.251';

// '5.5.250' еще не существует в `temporary_table`
INSERT INTO `temporary_table` (`group_key`, `count`) VALUES ('5.5.251', 1);

На последнем запросе мы получим желанную ошибку:
#1062 - Duplicate entry '5.5.251' for key 'group_key'

Если подобрать другой seed, например 33 (еще подойдут 37,41,45,49,53,57,61,65,…), так чтобы порядок значений выдаваемых RAND сыграл нам на руку раньше, то можно немного сократить запрос:

SELECT COUNT(*) FROM (SELECT 1 UNION SELECT 2)x GROUP BY MID([YOUR_QUERY], FLOOR(RAND(33)*2), 64)

На таком наборе данных мы избегаем второго шага, и тем самым нам достаточно всего двух строк в подзапросе.[/su_spoiler]

Ошибка переполнения типа данных

Подробнее здесь. Буду краток, вектор выглядит вот так:

SELECT (i IS NOT NULL) - -9223372036854775808 FROM (SELECT ([YOUR_QUERY])i)a

Пример ошибки:
BIGINT value is out of range in '(('5.5.25-log' is not null) - -(9223372036854775808))'
Данный способ покруче предыдущего так как позволяет вывести аж 475 символов вместо 64, но говорят что работает не на всех версиях MySQL. Проверить это у меня возможности нет, поэтому оставлю это на совести авторов. По крайней мере на версии 5.5 это работает точно.

Еще похожая вариация:

SELECT !(SELECT * FROM(SELECT USER())x)-~0

Это выдаст вот такую ошибку:
'((not((select 'root@localhost' from dual))) - ~(0))'

Гео-функции

Появились только в MySQL >= 5.7.5

SELECT ST_LatFromGeoHash(VERSION());
//Incorrect geohash value: '5.7.6-m16-log' for function ST_LATFROMGEOHASH

SELECT ST_LongFromGeoHash(VERSION());
//Incorrect geohash value: '5.7.6-m16-log' for function ST_LONGFROMGEOHASH

SELECT ST_PointFromGeoHash(VERSION(),0);
//Incorrect geohash value: '5.7.6-m16-log' for function ST_POINTFROMGEOHASH

Удобно, но 5.7.5 — это большая редкость на сегодняшний день. Тут я это наверное привел только ради того чтобы предложить альтернативу, предыдущим техникам и разбавить статью. Вряд ли это кто то применит на практике.

Заключение

Основной акцент в статье был сделан на то почему работает «Duplicate key»-метод (ради того чтобы не потерять мой пост отсюда), т.к. этот метод порой вызывает огромное недоумение. Ну а в целом буду собирать здесь все известные мне методы данной атаки.

Благодарю за внимание.

The post Error-Based SQL injection в MySQL first appeared on IntSystem.org.

Плагин в репозитории WordPress

Вот написал простенький плагин для WordPress-а, и добавил его в официальный репозиторий плагинов. Что делает? Позволяет изменять родительский комментарий для любого пользовательского комментария.

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

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

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

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

Как написать свой плагин для вордпресса?

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

Подготовка

Для начала создаем свой каталог для будущего плагина в /wp-content/plugins/, и одноименный php файл в нем, в нашем случае это /wp-content/plugins/change-comment-parent/change-comment-parent.php. В этот файл следует добавить специальный заголовок:

<?php
/*
Plugin Name: Change Comment Parent
Description: Simple plug-in for editing the parent comments to any user comments. Use it to edit the threaded structure comments.
Version: 1.0.0
Author: Dmitriy Amirov (InSys)
Author URI: https://intsystem.org/
*/

Все. Поздравляю. Свой плагин написан. Осталось включить его в админке. Правда беда в том, что он ничего не делает, т.к. пуст. Давайте добавлять функционал в него.

Обращу внимание, код в статье максимально упрощен намеренно для наглядности, не надо искать в нем ошибки и высказывать свое «фе» по этому по поводу :)

Декомпозиция задачи

Рассмотрим как работает наш плагин:

Т.е. нам нужно модифицировать саму страницу которая выводит записи и комментарии под ней. Добавить в нее немного HTML, JS и CSS. Так же чтобы придерживаться гайдлайну WordPress-а, а не хакрдкодить неправильные вещи, нужно указать адрес для Ajax зароса, который будет обрабатывать этот запрос.

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

Фронтэнд

Вот так выглядит интерфейс плагина (к каждому комментарию добавляются кнопки child, parent и apply):

Вот так это выглядит в виде кода:

if (get_option('thread_comments')) {
	add_filter('comment_text', array($this, 'commentTextAddHtml'), 10, 2);
}

function commentTextAddHtml($commentText, $comment)
{
	$html =
		'<div class="insys-comment-parent"><div>' .
			'<label><input type="radio" name="parent" value="' . $comment->comment_ID . '">parent</label>' .
			'<label><input type="radio" name="child" value="' . $comment->comment_ID . '">child</label>' .
			'<a href="#">apply</a> ' .
		'</div></div>';

	$commentText = $commentText . $html;

	return $commentText;
}

При этом нам нужно добавить стили, скрипты, и адрес бекенда. Делается это так:

wp_enqueue_style(
	'insys-comment-parent',
	plugins_url('style.css', __FILE__),
	array(),
	'1.0'
);

wp_enqueue_script(
	'insys-comment-parent',
	plugins_url('script.js', __FILE__),
	array('jquery'),
	'1.0'
);

wp_localize_script(
	'insys-comment-parent',
	'insysCommentParent',
	array( 'plugin_url'=> plugins_url('', __FILE__), 'ajax_url' => admin_url( 'admin-ajax.php' ))
);

Таким образом мы подключим style.css и script.js из каталога с плагином. Так же обратите внимание на wp_localize_script именно через нее мы передаем 'ajax_url' в JS.

Так выполняется Ajax запрос:

$.ajax({
	url: window.insysCommentParent.ajax_url,
	type: 'POST',
	data: {
		'action': 'insys_comment_parent',
		//...
	},
	//...
});

Бекэнд

На этой стороне нам необходимо обработать Ajax запрос, проверив права пользователя:

if (!current_user_can('moderate_comments' ) ) {
	return false;
}

if (is_admin()) {
	add_action('wp_ajax_insys_comment_parent', 'commentParentSet');
}

function commentParentSet(){
	$parent = $child = null;

	if (isset($_POST['parent'])) {
		$parent = intval($_POST['parent']);
	}

	if (isset($_POST['child'])) {
		$child = intval($_POST['child']);
	}

	if (empty($child)) {
		die('error');
	}

	if (!$parent || $child == $parent) {
		$parent = 0;
	}

	/* @var $wpdb wpdb */
	global $wpdb;

	$wpdb->query("UPDATE wp_comments SET comment_parent = " . intval($parent) . " WHERE comment_ID = " . intval($child) . "");

	die('ok');
}

Все просто и без изысков. Получили два значения, выполнили запрос. Боюсь что добавить тут больше нечего.

Как добавить плагин на wordpress.org?

Ничего сложного тут нет.

Readme.txt

В первую очередь нужно создать специальный файл readme.txt (пример), и положить этот файл в каталог с плагином. Этот файл содержит всю информацию которая будет выводится на странице с описанием плагина на https://wordpress.org/plugins/. Так же есть специальная утилитка для валидации этого файла.

Модерация

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

Для этого регистрируемся, переходим в раздел разработчиков в раздел Add Your Plugin. Заполняем форму, добавляем zip архив с плагином, и отсылаем.

К слову сказать мне пришлось ждать не очень долго, всего три дня. Пришло вот такое письмо:

Репозиторий плагина

Вся работа с плагином осуществляется через SVN репозиторий (честно говоря, не пользовался SVN до этого момента ни разу, и после GIT он мне показался таким топроным, что с трудом себя заставил разобраться с ним). В нем для нас уже любезно созданы специальные каталоги:
./assets/
./branches/
./trunk/
./tags/

Текущую версию закидываем в каталог ./trunk/. А также в каталоге ./tags/ следует создать подкаталог с номером версии плагина, например ./tags/1.0/. И сохраняем все это в репозитории.

При этом когда вы дорастете до новой версии плагина, то вы должны в каталоге ./tags/ по примеру выше создать подкаталог с именем новой версии плагина, куда следует залить файлы новой версии.

Кастомизация страницы плагина

Как уже было написано выше, информация для этой страницы берется из файла readme.txt. Но помимо этого, можно указать логотип плагина, и картинку шапки для страницы с плагином. Для этого в каталог ./assets/ можно закинуть следующие файлы:

• icon-128×128.png — лого
• icon-256×256.png — лого для retina
• banner-772×250.jpg — картинка в шапке
• banner-1544×500-rtl.jpg — картинка в шапке для retina

Туда же можно добавить скриншоты (файлы с именами screenshot-1.png, screenshot-N.jpg), которые будут добавлены в соответствующий раздел.

Заключение

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

Ну а я теперь полноценный официальный wordpress-разработчик. А мой плагин за три дня установили целых 6(!) человек, хотя мне кажется даже эти люди — случайность :D

The post Пишем свой плагин для WordPress, добавляем в каталог плагинов first appeared on IntSystem.org.

Бесконечная война

Автор блога IntSystem.Org Дмитрий Амиров, утверждающий, что взломал Keycaptcha, называет captcha атавизмом, который заставляет пользователя совершать ненужные действия, не обеспечивая должной защиты. «Это раньше распознавание символов с картинки для компьютеров было сложной задачей, сейчас все это обходимо, с пазлами — то же самое, — объясняет Амиров РБК. — Взломщик, если задастся целью, сможет легко обойти любую интерактивную капчу. Очевидно, на смену ей должны прийти более продвинутые технологии». По его словам, на написание алгоритма для сбора мозаики Keycaptcha у Амирова ушел всего один вечер. Гарантировать стопроцентную защиту не может ни одна captcha, задача иная — сделать процесс взлома экономически нецелесообразным, парирует Владыкин.

Для тех кто не понял, это относится к моей статье про взлом KeyCaptcha.

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

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

Мне нужно больше сенсаций! Пойду еще что-нибудь похекаю :)

The post Теперь в РБК есть абзац про меня :) first appeared on IntSystem.org.

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

Товаров в каталоге около 10 000. Картинок у каждого в среднем 30. Плюс 3 размера каждой картинки (large, medium, small), итого около 900 000 различных изображений (это около 80ГБ). Товары в каталоге динамичны — появляются, удаляются. Т.е. и за актуальностью картинок тоже надо бы следить.

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

Подытожим наши требования:

• проксировать картинки с удаленного сервиса и сохранять их локально
• если есть уже сохраненная картинка, то отдавать ее
• автоматически ресайзить картинки, пересохранять их в progressive JPEG
• минимизировать обращения к удаленному серверу, а именно:
  • если удаленная картинка не найдена, то такой ответ сервиса кешировать
  • если сервис упал, то такие ответы тоже кешировать
  • если есть уже сохраненная картинка бОльшего размера, то использовать ее (т.е. взять ее, отресайзить, сохранить, и отдать пользователю), без обращения к удаленному сервису
• в случае ошибки отдавать картинку-заглушку

Использовать PHP или любые другие скриптовые средства не хотелось, из-за их тормознутости/отжирания памяти. Все это удалось решить средствами NGINX.

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

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

Как видно из схемы, пришлось создавать два инстанса nginx (две разные секции server), и разделять задачи между ними. В принципе можно было бы обойтись и одним, но тогда кешировать запросы с ошибками не удалось бы. А если удаленный сервис вдруг упадет, то этого кеша очень сильно не хватало бы. Поэтому решено было остановится на такой схеме.

Для всего этого дела был приобретен отдельный сервер (далее image.site.com), который и стал у нас в дальнейшем сервером картинок.

NGINX

Для описанного выше, нам нужен модуль ngx_http_image_filter_module, который в общем то и позволяет ресайзить картинки. Но, к сожалению, по дефолту nginx собирается без него. Поэтому пришлось пересобрать nginx, с подключением этой библиотеки. Так же заодно добавил поддержку PCRE JIT, в мануале написано, что

использование PCRE JIT способно существенно ускорить обработку регулярных выражений.

А в нашем случае это будет довольно полезно. Полный процесс сборки описывать не буду, он хорошо описан в официальной документации. В моем случае добавились лишь следующие аргументы при сборке:
./configure ... --with-http_image_filter_module --with-pcre=[путь до pcre] --with-pcre-jit
В будущем еще планирую подключить HTTP/2. Будет полезно.

Основной инстанс

Собственно это тот инстанс, что открыт на 80 и 443 портах и доступен снаружи.

В этой секции основной упор был сделан на директиву proxy_store. Что она дает? Она сохраняет проксируемый файл в указанном каталоге, как есть, с сохранением структуры каталогов. Для нашей задачи подходит, как нельзя лучше. Конфиг nginx для этой секции:[su_spoiler title=»Показать конфиг основного инстанса NGINX» style=»fancy»]

server {
	#...
	error_page 403 404 405 415 500 502 503 504 /nophoto/nophoto.jpg;

	location ~* .*(?<extension>jpg|jpeg|png|gif)$ {
		error_page 403 404 405 415 500 502 503 504 /nophoto/nophoto.$extension;
		access_log off;

		limit_except GET {
			deny all;
		}

		location ~* ^/images/item\d?/.+$ {
			expires max;

			try_files "/imdata${uri}" @proxy_local;
		}
	}

	location @proxy_local {
		proxy_temp_path /var/www/cust_images/data/temp;

		proxy_store	"${root_path}/imdata${uri}";
		proxy_store_access user:rw group:rw all:r;

		proxy_intercept_errors on;

		proxy_method			GET;
		proxy_pass_request_body		off;
		proxy_pass_request_headers	off;

		proxy_pass http://0.0.0.0:8085;
	}
	#...
}

[/su_spoiler]Разберем по функциональным блокам.

Картинка-заглушка

error_page 403 404 405 415 500 502 503 504 /nophoto/nophoto.jpg;

location ~* .*(?<extension>jpg|jpeg|png|gif)$ {
	error_page 403 404 405 415 500 502 503 504 /nophoto/nophoto.$extension;
	#...
}

По дефолту, на любой ошибочный запрос отдается картинка /nophoto/nophoto.jpg (мало ли кто набрал вручную имя домена где у нас лежат картинки или пытается скачать какую нибудь другую страницу).

Но если к серверу обратились за картинкой, а ее нет, мы отдаем картинку в нужном формате (т.е. хотят PNG но ее на сервере нету, вернется /nophoto/nophoto.png и т.д.). Для этого в каталоге /nophoto/ лежат картинки всех перечисленных форматов.

Существующие картинки

Тут все просто:

location ~* ^/images/item\d?/.+$ {
	expires max;

	try_files "/imdata${uri}" @proxy_local;
}

Если файл в каталоге /imdata/ есть, отдаем его, если нет, то переходим в секцию @proxy_local.

Запрос к внутреннему инстансу

Здесь мы уже видим ту самую диррективу proxy_store:

location @proxy_local {
	proxy_temp_path /var/www/cust_images/data/temp;

	proxy_store	"${root_path}/imdata${uri}";
	proxy_store_access user:rw group:rw all:r;

	proxy_intercept_errors on;

	proxy_method				GET;
	proxy_pass_request_body		off;
	proxy_pass_request_headers	off;

	proxy_pass http://0.0.0.0:8085;
}

которая сохраняет результат запроса в каталог /imdata/. Здесь происходит внутренний запрос к 0.0.0.0:8085, а точнее ко внутреннему инстансу NGINX о котором говорилось выше.

Причем если внутренний запрос вернет ошибку, например 404, то этот ответ сохранен не будет, а обработается в соответствии с указанной ранее директивой error_page, см. proxy_intercept_errors.

При этом обратите внимание на то что proxy_pass_request_body и proxy_pass_request_headers установлены в off. Зачем? Затем чтобы минимизировать трафик внутри между инстансами NGINX. Предполагается что клиент запрашивает картинку (т.е. обычный статичный файл), а это значит, что никаких заголовков, типа User-Agent, Referer и прочих, для запроса не нужно. И уж тем более не нужно тело запроса (параметры POST, PUT и т.д), так как таких запросов тут быть не должно вообще, и в конфиге я целенаправленно заблокировал все кроме GET и HEAD (см. limit_except).

Внутренний инстанс

Этот инстанс висит на 8085 порту, но доступ к нему извне закрыт фаерволом, т.к. по сути он нужен только для внутренних запросов, и светить наружу ему попросту не за чем.
[su_spoiler title=»Показать конфиг внутреннего инстанса NGINX» style=»fancy»]

proxy_cache_path
    /var/www/cust_images/data/cache
    levels=1:2
    keys_zone=remoteimages:10m
    inactive=60m
    max_size=1G;

server {
    #...
    image_filter_jpeg_quality     80;
    image_filter_buffer           10M;
    image_filter_interlace        on;

    location ~* ^(?<request_1>/images/item\d?/\d+/\d+/)(?<request_size>small|medium|large|full)(?<request_2>\_\d+\.(jpg|jpeg|png|gif))$ {
        proxy_temp_path               /var/www/cust_images/data/temp;

        proxy_cache                   remoteimages;
        proxy_cache_key               $proxy_host$uri;

        proxy_cache_min_uses          1;
        proxy_cache_lock              on;

        proxy_cache_valid             any                                 1m;
        proxy_cache_valid             400 404 408 415 500 502 503 504     1h;

        proxy_cache_use_stale         error timeout invalid_header updating http_500 http_502 http_503 http_504;

        proxy_connect_timeout         5s;
        proxy_read_timeout            5s;
        proxy_send_timeout            5s;

        proxy_method                  GET;
        proxy_pass_request_body       off;
        proxy_pass_request_headers    off;

        set $width  "-";
        set $height "-";

        location ~* .+/full\_\d+\.[a-z]+$ {
            proxy_pass "http://images.service.com${request_1}large${request_2}";

            set $width  "-";
            set $height "-";
        }

        location ~* .+/large\_\d+\.[a-z]+$ {
            if (-f "${root_path}/imdata${request_1}full${request_2}") {
                return 481;
            }

            proxy_pass "http://images.service.com${request_1}large${request_2}";

            set $width  625;
            set $height "-";
        }

        location ~* .+/medium\_\d+\.[a-z]+$ {
            if (-f "${root_path}/imdata${request_1}full${request_2}") {
                return 482;
            }

            if (-f "${root_path}/imdata${request_1}large${request_2}") {
                return 482;
            }

            proxy_pass "http://images.service.com${request_1}medium${request_2}";

            set $width  380;
            set $height "-";
        }

        location ~* .+/small\_\d+\.[a-z]+$ {
            if (-f "${root_path}/imdata${request_1}full${request_2}") {
                return 483;
            }

            if (-f "${root_path}/imdata${request_1}large${request_2}") {
                return 483;
            }

            if (-f "${root_path}/imdata${request_1}medium${request_2}") {
                return 483;
            }

            proxy_pass "http://images.service.com${request_1}small${request_2}";

            set $width  "-";
            set $height 100;
        }

        image_filter resize $width $height;
    }

    error_page 481 =200 @local_large;
    error_page 482 =200 @local_medium;
    error_page 483 =200 @local_small;

    location @local_large {
        try_files "/imdata${request_1}full${request_2}" =404;

        image_filter resize 625 -;
    }

    location @local_medium {
        try_files "/imdata${request_1}large${request_2}" "/imdata${request_1}full${request_2}" =404;

        image_filter resize 380 -;
    }

    location @local_small {
        try_files "/imdata${request_1}medium${request_2}" "/imdata${request_1}large${request_2}" "/imdata${request_1}full${request_2}" =404;

        image_filter resize - 100;
    }
}

[/su_spoiler]
С этой секцией уже посложнее. Сразу поясню по размерам картинок:
[su_table]

[/su_table]
(? — пропорциональное изменение размера)

Как видно, практически все используемые размеры нам не подходят (единственный спорный момент — использование старых картинок типа medium вместо новых large, т.к. у них разница составляет всего 14px, и можно было бы переверстать оригинальный шаблон, но было принято решение подгонять все в точности как надо нам).

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

Покажу то, как работает этот инстанс на примере запроса картинки medium в виде блок-схемы:

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

Кеширование

        proxy_cache                   remoteimages;
        proxy_cache_key               $proxy_host$uri;
 
        proxy_cache_min_uses          1;
        proxy_cache_lock              on;
 
        proxy_cache_valid             any                                 1m;
        proxy_cache_valid             400 404 408 415 500 502 503 504     1h;
 
        proxy_cache_use_stale         error timeout invalid_header updating http_500 http_502 http_503 http_504;

Как видно тут, кешируются все ответы удаленного ресурса: ошибки на 1 час, все валидные ответы на 1 минуту.

Зачем кешировать валидный ответ? В данном случае это делается для снижения количества обращений к удаленному сервису. Т.е. если в один момент два разных человека запросят одну и ту же картинку, то выполнится не два запроса на удаленный сервис, а один. Второй запрос будет стоять в очереди (proxy_cache_lock) ожидания завершения точно такого же предыдущего запроса.

Работа с картинкой

Проверка существования картинок осуществляется следующим образом:

        location ~* .+/medium\_\d+\.[a-z]+$ {
            if (-f "${root_path}/imdata${request_1}full${request_2}") {
                return 482;
            }

            if (-f "${root_path}/imdata${request_1}large${request_2}") {
                return 482;
            }

            #...
        }

Т.е. если найдена картинка по адресу ${root_path}/imdata${request_1}full${request_2} или ${root_path}/imdata${request_1}large${request_2} (где ${request_1} и ${request_2} — части URL запроса), то управление передается в отдельную секцию через код ошибки 482:

	error_page 482 =200 @local_medium;
	#...
	location @local_medium {
		try_files "/imdata${request_1}large${request_2}" "/imdata${request_1}full${request_2}" =404;

		image_filter resize 380 -;
	}

(да есть и другие способы передачи обработки запроса, например через rewrite, try_files и прочее, но такой способ через error_page мне показался наиболее лаконичным)

Если же сохранной ранее картинки бОльшего размера нету, то обращаемся за ней на удаленный сервис, и ресайзим ее:

        location ~* .+/medium\_\d+\.[a-z]+$ {
            #...

            proxy_pass "http://images.service.com${request_1}medium${request_2}";

            set $width  380;
            set $height "-";
        }

        image_filter resize $width $height;

и полученный результат отдаем.

Честно сказать, очень печалит подход к секции if в nginx, а точнее ее неявное преобразование в еще один location. И следующее отсюда отсутствие возможности реализовывать вложенные if, отсутствие конструкции else. Хотя с другой стороны, это все таки конфигурационный файл, а не язык программирования.

Обновление картинок

Как помним из вступления, нам нужна была еще динамика. Т.е. добавление/удаление картинок.

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

Было решено приделать систему поддерживающую актуальность сохраненных картинок. Работает очень просто. На сервере проекта site.com раз в сутки по крону парсится список всех товаров, вытаскиваются все ссылки на картинки, и составляется такой список всех картинок:
http://images.service.com/images/item123/123/123/large_123.jpg
http://images.service.com/images/item234/234/234/large_234.jpg
...
[и еще 300 000 линков на прочие картинки]
Затем на сервере картинок images.site.com (тот самый про который и написан этот пост), так же раз в сутки этот файл скачивается wget-ом, после чего стартует скрипт который и обрабатывает данный список.

Алгоритм очень прост. Проверяем существование этого файла в каталоге /imdata/, если файла нет, то делаем HEAD запрос к локальному серверу NGINX. Можно было бы и внутри скрипта CURL-ом напрямую скачивать картинку с удаленного сервиса, но зачем? У нас же это уже реализовано, пусть и средствами веб сервера, но этого вполне достаточно.

В целом сам скрипт чуть сложнее, добавлена блокировка (от запуска нескольких копий скрипта), кеш списка уже скаченных картинок и буфер (в целях снижения нагрузки на жесткий диск). Если кому интересно, то можно ознакомиться с исходным кодом:
[su_spoiler title=»Скрипт для скачивания новых картинок» style=»fancy»]

<?php

define('APP_DIR', rtrim(dirname(__FILE__), '\//') . DIRECTORY_SEPARATOR);

$conf = [
	'lock'		 => APP_DIR . 'lock.tmp',
	'list'		 => APP_DIR . 'images.txt',
	'ready'		 => APP_DIR . 'images_ready.txt',
	'error'		 => APP_DIR . 'error.log',
	'imagesDir'	 => '/var/www/cust_images/data/www/images.site.com/imdata/',
];

$fp = fopen($conf['lock'], 'w');

if(!flock($fp, LOCK_EX | LOCK_NB)) {
    echo 'Sync script has already started';
    exit(-1);
}

register_shutdown_function(
	function() use ($fp){
		flock($fp, LOCK_UN | LOCK_NB);
		fclose($fp);
	}
);

set_time_limit(0);
ignore_user_abort(true);
ini_set('memory_limit', '256M');

if (file_exists($conf['list'])) {
	$imagesList = file($conf['list']);
	$imagesList = array_map('trim', $imagesList);
} else {
	$imagesList = array();
}

if (file_exists($conf['ready'])) {
	$imagesReady = file($conf['ready']);
	$imagesReady = array_map('trim', $imagesReady);
} else {
	$imagesReady = array();
}

$imagesToSync = array_diff($imagesList, $imagesReady);
unset($imagesList, $imagesReady);


$buffer = [];
$funcFlushBuffer = function() use (&$buffer, $conf) {
	file_put_contents($conf['ready'], implode("\n", $buffer) . "\n", FILE_APPEND);
	$buffer = [];
};

while (($item = array_pop($imagesToSync))) {
	if (count($buffer) > 500) {
		$funcFlushBuffer();
		usleep(500000); //sleep 100 ms
	}

	$path = str_replace(['http://images.service.com/', 'https://images.service.com/'], '/', $item);
	$path = str_replace('large_', 'full_', $path);

	if (file_exists($conf['imagesDir'] . $path)) {
		$buffer[] = $item;
		continue;
	}

	$url = str_replace(['http://images.service.com/', 'https://images.service.com'], 'http://images.site.com/', $item);
	$url = str_replace('large_', 'full_', $url);

	$ch = curl_init();
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	curl_setopt($ch, CURLOPT_URL, $url);
	curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);
	curl_setopt($ch, CURLOPT_HEADER, true);
	curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');
	curl_setopt($ch, CURLOPT_NOBODY, true);
	curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_0);
	curl_setopt($ch, CURLOPT_FORBID_REUSE, true);
	curl_setopt($ch, CURLOPT_FRESH_CONNECT, true);

	$content = curl_exec($ch);
	curl_close($ch);

	$buffer[] = $item;
	$funcFlushBuffer();

	usleep(100000); //sleep 100 ms
	
	if (!file_exists($conf['imagesDir'] . $path)) {
		file_put_contents($conf['error'], date(DATE_ATOM) . ' error sync ' . $path . "\n", FILE_APPEND);
	}
}

[/su_spoiler]

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

Итог

В итоге получилась такая схема взаимодействия:

Теперь все картинки кешируются у нас, и падений удаленного сервиса можно не боятся.

Как видите NGINX — очень гибкий веб сервер :)

The post Проксирование, ресайз и кеширование картинок с помощью NGINX first appeared on IntSystem.org.

Сегодня этому блогу исполняется целых четыре года. Но, наверное, это не самое главное событие, которым я хочу похвастаться в этом посте. Главнее то, что, как кто то уже заметил, я вернул этот блог из «забвения», сдул двухгодовалый слой пыли, и снова начал им заниматься. И это несомненно здорово!

Мои мысли, планы на будущее и традиционный обзор интересных постов за последнее время под катом

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

За два года, к сожалению, растерял практически всех своих постоянных подписчиков/комментаторов, о чем очень печалюсь… Ребята, если вы вдруг это читаете, вернитесь, я хороший :) Но, как ни странно, это единственный отрицательный фактор, проявившийся за два года отсутствия активности. Позиции в поисковых системах подросли, трафик остался на прежнем уровне. И вон, не так давно, яндекс дал мне ТИЦ 30.

Перейдем к главному. Не буду разбивать посты на категории, т.к. их не очень много, но вот то на что можно обратить внимание за последние два года:

• Переехал на новый сервер — собственно сказ о том что мне дало толчок снова начать вести бог, а именно — переезд на выделенный сервер;
• Ускоряем генерацию страниц WordPress в три раза — настроиваю сервер, окружение, плагины, правлю код вордпреса — в итоге получаю существенный прирост скорости;
• Неявная проблема ON DUPLICATE KEY и AUTO INCREMENT — какую свинью вам может подложить Innodb Mysql при использовании AUTO INCREMENT;
• Переехал на HTTPS, включил HTTP/2 — я вливаюсь во всеобщую волну истерии по поводу необходимости HTTPS, ну и плюс важное событие — включаю поддержку протокола  HTTP/2;
• Почему FastVps лучше чем sweb — ну не могу не сакцентировать внимание на такой наглядной разнице между хостерами (не реклама, мое наблюдение);
• Как работать с IPv6 в PHP — перевод зарубежной статьи, с учетом постепенного перехода на IPv6, я думаю, это будет полезно;
• Gitolite, Автодеплой dev… или как я работаю с GIT — организация git репозиториев у меня на сервере.

На этом, к сожалению все. В принципе, если учесть что это все по сути написано за три месяца, то, я думаю, ничего страшного, что так мало :)

В планах рассказать про интересный опыт работы с картинками в nginx, дописать статью про сертификаты (в продолжение статьи про асимметричное шифрование) и атаку MitM, перевести еще пару интересных статей, написать про все работы, что я провел, улучшая/оптимизируя блог, и еще несколько интересных задумок.

И (надеюсь у меня это получится) хочу, в целях привлечения посетителей, организовать небольшой хак квест. Задумки сценария есть. В качестве приза только не знаю, что предложить. Одна из идей — год бесплатного хостинга у меня на сервере. Только не уверен что это будет кому-то интересно) но других идей нет.

Ну вот в принципе и все что я мог хотел рассказать в этом сообщении. Спасибо за внимание =)

The post И вот четыре года прошло… first appeared on IntSystem.org.

Cхема деплоя dev версии

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

Gitolite позволяет управлять репозиториями, настраивать доступ, в общем практически все что нужно и даже чуточку больше. Подробнее об этом можно глянуть в википедии. Но если в кратце, то gitolite предоставляет доступ к репозиториям посредством ssh, авторизуя пользователей по ключам. С помощью коммитов в специальный репозиторий мы управляем остальными репозиториями. В общем до жути удобно, и максимально просто.

Установка Gitolite

Это очень просто. Для начала создадим специального юзера в системе (допустим server_git), а после от его имени выполняем:
cd ~
git clone git://github.com/sitaramc/gitolite
mkdir -p bin
gitolite/install -to ./bin

После вам нужно закинуть на сервер ваш публичный ssh ключ. Закиньте его в тот же каталог (key.pub), и выполняйте:
./bin/gitolite setup -pk key.pub
Это и все, gitolite установлен. По умолчанию будет создано два репозитория, gitolite-admin.git и testing.git. Первый, как вы уже понимаете — нужен для управления репозиториями. Он будет доступен по адресу:
ssh://server_git@server.com/gitolite-admin.git
(естественно для авторизации нужен приватный пара-ключ для key.pub с которым вы устанавливали gitolite одним шагом назад)

Администрирование Gitolite

Все в принципе очень просто. Клонируем к себе ssh://server_git@server.com/gitolite-admin.git и с помощью коммитов в этот репозиторий управляем доступом/созданием любых репозиториев. Для того чтобы добавить пользователя добавляем в каталог keydir/ публичный ключ этого пользователя. Создание нового репозитория еще проще. Редактируем файл conf/gitolite.conf. Добавляем репозиторий вот так:

repo newrepo
    RW+     =   user_first
    RW+     =   user_second

При этом в папке keydir/ должны быть ключи user_first.pub и user_second.pub соответствующих пользователей. Коммитим это все и пушим в репозиторий. После этого на сервере будет создан репозиторий newrepo, к которому будут иметь доступ соответствующие пользователи.

Автодеплой

С этим чуть сложнее. Я опишу как это делал именно я. Не спорю, может быть для этого есть более легкие методы. Но я сделал как смог, и заниматься поисками других вариантов у меня просто не было ни времени ни желания. Многие тащатся от монстров типа capistrano и иже с ним. Но у меня еще не возникало каких то нерешаемых с нынешней системой развертывания dev версий проектов. В продакшн же лью руками.

Вкратце — система построена на хуках, и подтягивания изменений из основного репозитория в репозиторий dev версии. Вобщем глянем на схему:

Всей музыкой руководит приложение (назовем его AutoDeployApp), которое клонирует новый репозиторий если его еще нет (git init и git clone), или подтягивает изменения в существующий (git fetch и git reset) репозиторий Dev версии проекта.

AutoDeployApp

В моем случае это набор простых скриптов (скачать appDeploy). Распаковываем в ~/projects/. Открываем ~/projects/config.php и правим, в моем случае конфиг выглядит вот так:

define('CONFIG_BASEPATH', '/var/www/server_git/data/');
define('CONFIG_DEFAULT_REPOSITORIES', CONFIG_BASEPATH . 'repositories/'); //gitolite repos
define('CONFIG_DEFAULT_CONTENTS', CONFIG_BASEPATH . 'www/git.intsystem.org/'); //path to live versions

define('CONFIG_REMOTE_REPO', 'ssh://server_git@server-git-local/');

Где ssh://server_git@server-git-local/ адрес сервера с gitolite. Т.к. хук обновляет репозиторий через SSH, осуществляя подключение к самому себе же, я просто создал алиас server-git-local в ~/.ssh/config в таком виде:

Host server-git-local
  HostName git.intsystem.org
  User server_git
  StrictHostKeyChecking no
  IdentityFile ~/.ssh/server_git

При этом нужно сгенерировать пару приватный/публичный ключ (~/.ssh/server_git и ~/.ssh/server_git.pub) с помощью команды ssh-keygen (надеюсь с этим вы справитесь).

Теперь в репозиторий ssh://server_git@server.com/gitolite-admin.git нужно закинуть ~/.ssh/server_git.pub, и для каждого репозитория добавлять RW+ = server_git, в качестве примера:

repo testing
    RW+     =   insys
    RW+     =   server_git

Хук в Gitolite

Добавляем хук в ~/.gitolite/hooks/common/post-receive следующего содержания:

#!/bin/bash

CURRENT_DIR=`pwd`

/var/www/server_git/data/projects/hook_git.php "$CURRENT_DIR" "$GL_REPO_BASE" "$GL_REPO" >> /var/www/server_dev/data/projects/log.txt 2>&1

exit 0

Теперь на каждый пуш новых коммитов будет вызываться данный хук. И при необходимости обновлять dev версию проекта.

Конфиг вебсервера

В панели ISP есть такая замечательная функция которая называется автоподдомены. Суть данной настройки заключается в том что любой каталог расположенный в корневой папке, становится доступен в виде поддомена. Вот пример конфига апача:

	...
	ServerName git.intsystem.org
	ServerAlias *.git.intsystem.org
	VirtualDocumentRoot /var/www/server_git/data/www/git.intsystem.org/%1
	...

Создаем новый репозиторий с dev версией

Для начала создаем новый репозиторий в gitolite:

repo testproject
    RW+     =   user
    RW+     =   server_git

Добавляем проект в AutoDeployApp, открываем файл ~/projects/projects.txt, добавляем новый проект:

testproject:testproject:testproject

Создаем новый поддомен для dev версии, создаем каталог ~/www/git.intsystem.org/testproject/.

Теперь любой пуш в ssh://server_git@server.com/testproject.git будет сразу виден по адресу testproject.git.intsystem.org

Немного о production

Идея автоматического применения изменения в продакшн мне не очень нравится, но и каждый раз лазить на сервер через ssh чтобы сделать git pull тоже надоедает. Для этого у меня есть простенький скриптик helper-git. Имеет простейший функционал:

Доступ запаролен (helper-git.php?pass=[pass]), смотрим сам файл

define('ACCESS_PASSWORD', 'doe2njkle');

С виду хоть и выглядит топорно и отчасти по-ламерски, но меня вполне устраивает.

Итог

Итого имеем 4 репозитория на каждый проект:

• Локальный.
• Основной (в который пушим из локального).
• Dev-репозиторий (в него автоматом подтягиваются изменения из основного по хукам).
• Продакшн (в него ручками).

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

Ну в общем вот как то так. Да может не совсем понятно объяснил, но, честно сказать, я сам иногда перестаю понимать как это все работает :)

The post Gitolite, Автодеплой dev… или как я работаю с GIT first appeared on IntSystem.org.