Ars Longa, Vita Brevis » ошибка

Linux, консоль и деванагари

Vladimir — Mon, 05 Sep 2011 15:51:08 +0000

В то время, когда наши корабли бороздят просторы Вселенной…

Недавно отлаживал небольшой скрипт, транслитерирующий текст, записанный в системе IAST или ITRANS, на деванагари. Так как на домашней машине стоит Linux, то логично, что скрипт отлаживался в Linux — в терминале.

И тут меня ожидал огромный сюрприз…

В качестве теста брался отрывок из Брихадараньяка-упанишады, выглядящий следующим образом (в IAST):

pūrṇamadaḥ pūrṇamidam pūrṇāt pūrṇamudacyate
pūrṇasya pūrṇamādāya pūrṇamevāvaśiṣyate

По-русски это примерно так:

То — бесконечность, и это — бесконечность. Бесконечность исходит из бесконечности,
Обретая бесконечность бесконечного, она остается лишь бесконечностью.

На деванагари результат должен выглядеть так:

पूर्णमदः पूर्णमिदम् पूर्णात् पूर्णमुदच्यते
पूर्णस्य पूर्णमादाय पूर्णमेवावशिष्यते

Как оказалось, если взять результат, сохранить в файл, а потом вывести на экран (например, командой cat), то получится полный бред:

परणमदः परणमिदम परणात परणमदचयत
परणसय परणमादाय परणमवावशिषयत

В IAST это будет

paraṇamadaḥ paraṇamidama paraṇāta paraṇamadacayata
paraṇasaya paraṇamādāya paraṇamavāvaśiṣayata

Что в корне отличается от того, что было в оригинале.

Тут нужно сделать парочку лирических отступлений:

В деванагари есть такая особенность, что символы согласных звуков «по умолчанию» содержат гласный a. То есть क — это ka, а не k. Отсутствие этого a обозначается специальным подстрочным символом (символ вирама или халант). Например, комбинация, соответствующая звуку k будет записываться как क्.
Вторая особенность — гласные звуки имеют два варианта написания: гласный после гласной (или сам по себе) и после согласной записываются по-разному (во втором случае обычно используются диакритические знаки). Например, u — ku: उ — कु.

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

पूर्णमदः — पू र् ण म दः — pū r ṇa ma daḥ
परणमदः — प र ण म दः — pa ra ṇa ma daḥ

Можно заметить одну особенность: терминал «обрезает» надстрочные и подстрочные символы (причём обрезает наглухо — при копировании копируется не исходный вариант, а обрезанный). Например, в पू подстрочный символ обозначает гласный ū (лирическое отступление №2), если подстрочный символ «обрезать», то останется просто प, который в соответствии с лирическим отступлением №1 будет pa.

क	ka	=>	क	ka
का	kā	=>	का	kā
कि	ki	=>	कि	ki
की	kī	=>	की	kī
कु	ku	=>	क	ka
कू	kū	=>	क	ka
कृ	kṛ	=>	क	ka
कॄ	kṝ	=>	क	ka
कॢ	kḷ	=>	क	ka
कॣ	kḹ	=>	क	ka
के	ke	=>	क	ka
कै	kai	=>	क	ka
को	ko	=>	को	ko
कौ	kau	=>	कौ	kau
कँ	kam̐	=>	क	ka
कं	kaṁ	=>	क	ka
कः	kaḥ	=>	कः	kaḥ
क्	k	=>	क	ka

Видим, что в терминале очень не везёт гласным u, ū, ṛ, ṝ, ḷ, ḹ, e и дифтонгу ai — они тихо превращаются в a. Вирама также погибает смертью храбрых, в результате чего к согласным добавляется звук a. Анусвара (ṃ) и чандрабинду (m̐) обрезаются.

Какой можно сделать вывод? Индийские тексты в терминале нечитаемы. Вообще. И это в век повсеместного Unicode и UTF-8! Честно говоря, в Linux достаточно проблем с Unicode: apport не воспринимает русские символы, command-not-found вылетает с ошибкой на не английских символах, Inkscape некорректно отображает деванагари, те же проблемы в LibreOffice… Грустно…

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so

Vladimir — Mon, 22 Aug 2011 23:34:06 +0000

Исправление ошибки установки Flash Player в Ubuntu 11.10/AMD64

При обновлении Ubuntu Natty Narwhal до текущей альфы Oneiric Ocelot на архитектуре AMD64 возникает неприятная ошибка при обновлении пакета flashplugin-installer (Flash Player):

package flashplugin-installer 10.3.183.4ubuntu3 failed to install/upgrade:
nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so

Лечение довольно простое:

Необходимо включить поддержку multiarch, если она еще не включена:

echo foreign-architecture i386 > /etc/dpkg/dpkg.cfg.d/multiarch
apt-get update

Это позволит устанавливать пакеты для архитектуры i386 на AMD64.
Затем нужно установить пакеты libnss3:i386 и libcurl3:i386:

aptitude install libnss3:i386 libcurl3:i386

В зависимостях подтянутся пакеты libnspr4:i386 и libsqlite3-0:i386.

После этого можно спокойно (пере)установить пакет flashplugin-installer — всё будет работать.

С отчётом об ошибке и комментариями пользователей можно ознакомиться здесь.

php: symbol zlibVersion, version libmysqlclient_16 not defined in in file libmysqlclient.so.16 with link time reference

Vladimir — Mon, 30 May 2011 16:13:54 +0000

Быстрое исправление 'relocation error'

Не везёт мне с PHP на CentOS…

Ситуация: имеется сервер на CentOS с установленной CPanel. PHP в случайные моменты времени завершается с ошибкой вида

php: relocation error: php: symbol zlibVersion, version libmysqlclient_16 not defined in in file libmysqlclient.so.16 with link time reference

Вместо zlibVersion может быть другое имя, например crc32.

Из-за CPanel/WHM возможности ограничены опциями, предоставляемыми EasyApache — обновить MySQL/PHP штатными средствами (например, через yum) не представляется возможным из-за риска сломать CPanel.

Текст ошибки явно указывает на проблему с версией библиотеки, поэтому в первую очередь нужно выянить, где на сервере находится libmysqlclient. В моём случае это /usr/lib64 и /usr/lib64/mysql.

Затем смотрим, какую из библиотек использует php:

$ ldd `which php` | grep libmysqlclient
libmysqlclient.so.16 => /usr/lib64/mysql/libmysqlclient.so.16 (0x00000034c6000000)
$ ls -la `/usr/lib64/mysql/libmysqlclient.so.16`
lrwxrwxrwx 1 root root 27 May 29 00:08 /usr/lib64/mysql/libmysqlclient.so.16 -> libmysqlclient.so.16.0.0*

Но libmysqlclient.so.16.0.0 существует и в /usr/lib64, и в /usr/lib64/mysql, поэтому посмотрим, где нужный символ есть:

$ nm /usr/lib64/mysql/mysql/libmysqlclient.so.16.0.0 | grep zlibVersion
nm: libmysqlclient.so.16.0.0: no symbols
$ nm /usr/lib64/mysql/libmysqlclient.so.16.0.0 | grep zlibVersion
00000034c60d64b0 T zlibVersion

Меняем символьную ссылку на нужный файл:

rm -f /usr/lib64/mysql/libmysqlclient.so.16
cd /usr/lib64/mysql
ln -s ../libmysqlclient.so.16.0.0 libmysqlclient.so.16

После чего ошибка исчезает.

WordPress, поиск и кириллица

Wandering Soul — Sun, 02 Jan 2011 14:11:53 +0000

Правильные результаты поиска при использовании красивых ссылок

Есть у WordPress одна неприятная особенность: при использовании красивых ссылок и их использовании при поиске кириллических (или любых не-ASCII) слов получается совсем не тот результат, который ожидается.

Например, есть такая ссылка:

http://blog.sjinks.pro/search/%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F/

%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F — это слово «Генерация», закодированное функцией urlencode().

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

Проблема заключается в том, что WordPress выдаёт разные результаты для двух казалось бы идентичных запросов:

«Традиционный поиск» — без использования красивых ссылок:
http://blog.sjinks.pro/?s=%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F
Поиск с использованием красивых ссылок:
http://blog.sjinks.pro/search/%D0%93%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F/

В первом случае WordPress вернул 6 результатов, во втором — только один. При этом в первом случае искомое слово отображается правильно, во втором — нет.

Если посмотреть на запросы при помощи плагина SQLMon, увидим такую картину: в первом случае запрос имеет вид

SELECT SQL_CALC_FOUND_ROWS wp_posts.*
FROM wp_posts
WHERE 1=1
AND (((wp_posts.post_title LIKE '%Генерация%') OR (wp_posts.post_content LIKE '%Генерация%')))
AND wp_posts.post_type IN ('post', 'page', 'attachment')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')
ORDER BY wp_posts.post_date DESC
LIMIT 0, 10

Во втором случае запрос выглядит страшнее:

SELECT SQL_CALC_FOUND_ROWS wp_posts.*
FROM wp_posts
WHERE 1=1
AND (((wp_posts.post_title LIKE '%\\%D0\\%93\\%D0\\%B5\\%D0\\%BD\\%D0\\%B5\\%D1\\%80\\%D0\\%B0\\%D1\\%86\\%D0\\%B8\\%D1\\%8F%') OR (wp_posts.post_content LIKE '%\\%D0\\%93\\%D0\\%B5\\%D0\\%BD\\%D0\\%B5\\%D1\\%80\\%D0\\%B0\\%D1\\%86\\%D0\\%B8\\%D1\\%8F%')))
AND wp_posts.post_type IN ('post', 'page', 'attachment')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')
ORDER BY wp_posts.post_date DESC
LIMIT 0, 10

Создаётся впечатление, что WordPress забыл выполнить urldecode(). Вполне вероятно, что этим никто и не озадачивался: при передаче параметров через строку запроса (как в первом случае) ответственность за перевод значений в «читаемую форму» лежит на PHP. А во втором случае закодированное значение является частью URI, поэтому PHP его не трогает.

Решение тривиально: в файл functions.php темы нужно добавить такой код (можно оформить плагином, но банально лень):

Хак применяется и на этом блоге, поэтому приведённые скриншоты более не воспроизводимы.

ionCube и xCache

Vladimir — Fri, 10 Dec 2010 04:58:09 +0000

Случайные segmentation fault

Вчера столкнулся с неожиданными ошибками php (segmentation fault) на сервере, на котором стояли ionCube Loader и xCache. Причем падения происходили исключительно при работе wp-cron.php.

Тем, у кого похожая проблема и нет желания читать дальше:

Загружайте xcache при помощи директивы extension, а не zend_extension (скажу честно, я не понял, в чём существенная разница, но, с другой стороны, на исходный код ionCube Loader никто посмотреть не даст).
Наложите мой патч на исходный код xCache. Его можно найти в первом комментарии к сообщению об ошибке.

Теперь технические подробности для тех, кому интересно.

Падение происходит непосредственно в ionCube Loader (дайте исходник!!!), трасса вызовов выглядит примерно так:

#0 0x00007ffff452abdb in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#1 0x00007ffff4528a95 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#2 0x00007ffff452adb7 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#3 0x00007ffff4528a95 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#4 0x00007ffff452adb7 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#5 0x00007ffff4528a95 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#6 0x00007ffff452adb7 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#7 0x00007ffff4528a95 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#8 0x00007ffff452adb7 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#9 0x00007ffff4528a95 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#10 0x000000000078b12d in zend_call_function (fci=0x7fffffff96c0, fci_cache=0x7fffffff9710) at /root/php5-5.3.3/Zend/zend_execute_API.c:963
#11 0x0000000000679c2c in zif_call_user_func_array (ht=2, return_value=0x8719540, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /root/php5-5.3.3/ext/standard/basic_functions.c:4788
#12 0x00000000007d0e2a in zend_do_fcall_common_helper_SPEC (execute_data=0x56b5480) at /root/php5-5.3.3/Zend/zend_vm_execute.h:316
#13 0x00000000007d550f in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x56b5480) at /root/php5-5.3.3/Zend/zend_vm_execute.h:1606
#14 0x00000000007d0274 in execute (op_array=0x2c5ace0) at /root/php5-5.3.3/Zend/zend_vm_execute.h:107
#15 0x00007ffff452adb7 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#16 0x00007ffff4528a95 in ?? () from /usr/lib/php5/20090626/ioncube_loader_lin_5.3.so
#17 0x000000000078b12d in zend_call_function (fci=0x7fffffff9b90, fci_cache=0x7fffffff9be0) at /root/php5-5.3.3/Zend/zend_execute_API.c:963
#18 0x0000000000679c2c in zif_call_user_func_array (ht=2, return_value=0x85fd8d8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /root/php5-5.3.3/ext/standard/basic_functions.c:4788
#19 0x00000000007d0e2a in zend_do_fcall_common_helper_SPEC (execute_data=0x56b4088) at /root/php5-5.3.3/Zend/zend_vm_execute.h:316
#20 0x00000000007d550f in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x56b4088) at /root/php5-5.3.3/Zend/zend_vm_execute.h:1606
#21 0x00000000007d0274 in execute (op_array=0x601eba0) at /root/php5-5.3.3/Zend/zend_vm_execute.h:107
#22 0x00000000007d0fed in zend_do_fcall_common_helper_SPEC (execute_data=0x56b3858) at /root/php5-5.3.3/Zend/zend_vm_execute.h:340
#23 0x00000000007d1526 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x56b3858) at /root/php5-5.3.3/Zend/zend_vm_execute.h:421
#24 0x00000000007d0274 in execute (op_array=0x79ab1b8) at /root/php5-5.3.3/Zend/zend_vm_execute.h:107
#25 0x000000000079ad95 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php5-5.3.3/Zend/zend.c:1266
#26 0x00000000007225c6 in php_execute_script (primary_file=0x7fffffffc3f0) at /root/php5-5.3.3/main/main.c:2288
#27 0x000000000087ef85 in main (argc=6, argv=0x7fffffffe6a8) at /root/php5-5.3.3/sapi/cgi/cgi_main.c:2117

Разбор кадров стека показал:

21 кадр: wp-cron.php через вызов do_action_ref_array() вызывает код, находящийся в закодированном файле; управление передаётся загрузчику ioncube (16 кадр);
15 кадр: закодированный файл вызывает do_action() — управление передаётся в нормальный код;
14 кадр: do_action() вызывает функцию из зашифрованного файла через call_user_func_array();
9 кадр: загрузчик получает управление;
8 кадр (а также 6, 4, 2): судя по адресу (0x00007ffff452adb7), совпадающему с адресом из 15 кадра, вызывается что-то не закодированное;
кадры 7, 5, 3, 1: похоже на вызов функций в закодированном файле из обычного кода;
0 кадр: segfault. Что интересно, не по адресу 0x00007ffff452adb7, а, судя по всему, на инструкцию позже (исходники дайте, блин!).

Естественно, что тех поддержка ionCube всё сваливает на xCache — ведь без xCache всё работает. Но в xCache с виду всё чисто.

Совершенно случайно обнаружилось, что если xCache загружать через директиву extension, то ошибки не происходит. С другой стороны, в обоих случаях выполняется один и тот же код (с разницей в том, что загружается первым: расширение PHP или расширение Zend). Лично мне кажется, что ошибка где-то в коде загрузчика ionCube, но разработчики последнего со мной не согласны.

UPD: в конечном итоге снёс xCache, поставил APC — полёт нормальный.
UPD2: а еще экспериментально выяснилось, что ionCube Encoder сохраняет в зашифрованном файле информацию о том, какая лицензия ionCube (именно лицензия на кодировщик!) использовалась при шифровании, что позволяет установить (сотрудникам ionCube), покупателя ionCube Encoder. Nick проговорился

ICS Security Fixes: исправление уязвимостей в прошлых версиях WordPress

Vladimir — Thu, 02 Dec 2010 14:10:06 +0000

Попытка сделать старые версии WordPress безопаснее.

Многие блоггеры не торопятся с обновлением WordPress, особенно когда дело касается новых релизов WordPress: по традиции, каждый новый релиз потребляет больше памяти, чем предыдущий, создаёт бóльшую нагрузку на базу и содержит новые, мало кому нужные функции А еще говорят, что нельзя обновляться до версии x.y.0, нужно обязательно ждать x.y.1

Что же, доля истины во всём этом есть, но есть и одно большое НО: все эти обновления, включая новые релизы, обычно содержат важные исправления безопасности, причём иногда разработчики об этом могут не догадываться.

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

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

Естественно, что таким образом можно исправить далеко не всё (например, уязвимость в Snoopy на FreeBSD так не исправить), но отфильтровать параметры запросов или запросы к базе данных вполне реально (хотя тоже не всегда).

Так родился плагин ICS Security Fixes.

Версия 0.1 содержит следующие исправления:

отключение whitelisting’а для трэкбэков/пингбэков (то, что было сделано в 3.0.2 и тянется с 1.x);
попытка борьбы с SQL truncation attack при регистрации пользователя;
исправления, призванные не допустить SQL injection attack при обработке трэкбэков;
исправление CVE-2008-4769;
Old slug redirect bug fix;
Попытка исправления ошибки cURL, связанной с перенаправлением на URI с протоколами file:// и scp:// (трудно сказать про работоспособность, ибо такой древний cURL найти трудно);
Исправление SQL injection в wp_insert_attachment();
Тупой способ для борьбы с подменой фидов;
Защита от атаки на генератор псевдослучайных чисел (надеюсь, что получилось — сгенерировать 80-гигабайтные радужные таблицы нет возможности);
Попытка защиты от 2.7.x/2.8.x admin remote code execution exploit;
Исправление Wordpress 2.5 Cookie Integrity Protection Vulnerability;
Исправление ошибки со сбросом пароля в 2.5.1.

Версия 0.2:

Исправление ошибок, связанных с активацией плагина;
Установка версии по умолчанию для скриптов и таблиц стилей в 0.0.

Версия 0.3:

Исправление ошибок в предыдущих версиях (спасибо Сергею Бирюкову за патч);
Сокрытие версий используемых таблиц стилей и скриптов (удаление параметра ver из строки запроса; кстати, Google рекомендует не использовать строку запроса в URL статических ресурсов);
Частично закрыта уязвимость SA23621 — пользователь получает одно и то же сообщение об ошибке и при неверном имени пользователя, и при неверном пароле. Тем не менее, проверка существования пользователя возможна путём использования функции напоминания пароля;
По многочисленным просьбам добавлено сокрытие версии плагина All in One SEO Pack.

Версия 0.4:

Закрытие уязвимостей, исправленных в WordPress 3.0.5 (r17393, r17387, r17400, r17406).

Хочу выразить большую благодарность Сергею Бирюкову за тестирование и патч, исправляющий ошибки. Спасибо!

Дальнейшее направление работы:

Бэкпортирование патчей уязвимостей для серии 3.x;
Бэкпортирование патчей и закрытие незакрытых уязвимостей для серии 2.x.

У кого есть ссылки на рабочие эксплойты для WordPress любых версий и кто может ими поделиться, а также те, кто готов помочь с тестированием — you are welcome!

Скачать последнюю версию ICS Security Fixes

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

UPDATE Feb 15, 2010:
Страница плагина теперь живёт здесь: http://blog.sjinks.pro/wordpress-plugins/ics-security-fixes/
Страница плагина на wordpress.org: http://wordpress.org/extend/plugins/ics-security-fixes/

Официальный русский WordPress и SSL

Vladimir — Wed, 01 Dec 2010 13:15:22 +0000

Исправление проблем с SSL при использовании официального русского WordPress

На днях понадобилось прикрутить к русскоязычному сайту, использующему WordPress, SSL. SSL требовался только в админке, поэтому решалось всё просто:

define("FORCE_SSL_LOGIN", true);
define("FORCE_SSL_ADMIN", true);

Но после логина и захода в панель администрирования браузер сказал, что соединение не является полностью защищённым — присутствовали объекты, которые загружались по HTTP, а не HTTPS.

Быстрый взгляд на исходный текст страницы и виновные найдены:

Эти три таблицы стилей грузятся с http, в то время как все остальные ресурсы грузятся с https. А путь (wp-content/languages/) указывает на то, что проблемы были вызваны файлами локализации. Заходим в wp-content/languages/, видим файл ru_RU.php, смотрим:

$wp_default_secret_key = 'впишите сюда уникальную фразу';

// Make the menu wider and correct some overlapping issues
function ru_accomodate_markup() {
global $locale, $wp_styles;

wp_enqueue_style($locale, WP_CONTENT_URL . "/languages/$locale.css", array(), '20100615', 'all');
wp_enqueue_style("$locale-ie", WP_CONTENT_URL . "/languages/$locale-ie.css", array(), '20100615', 'all');
if ( is_multisite() )
wp_enqueue_style("ms-$locale", WP_CONTENT_URL . "/languages/ms-$locale.css", array(), '20100615', 'all');
$wp_styles->add_data("$locale-ie", 'conditional', 'IE');

wp_print_styles();
}
add_action('admin_head', 'ru_accomodate_markup');

function ru_populate_options() {
add_option('rss_language', 'ru');
}
add_action('populate_options', 'ru_populate_options');

function ru_restore_scripts_l10n() {
global $wp_scripts;

if ( is_a($wp_scripts, 'WP_Scripts') ) {
do_action_ref_array('wp_default_scripts', array(&$wp_scripts));
}
}
add_action('init', 'ru_restore_scripts_l10n');

Очевидно, что проблема заключается в использовании константы WP_CONTENT_URL — если URL сайта начинается с http://, то вне зависимости от значений констант FORCE_SSL_xxx значение WP_CONTENT_URL всегда будет начинаться с http://. Что недопустимо при использовании SSL.

Лечение простое: заменить WP_CONTENT_URL на вызов функции content_url():

$wp_default_secret_key = 'впишите сюда уникальную фразу';

// Make the menu wider and correct some overlapping issues
function ru_accomodate_markup() {
global $locale, $wp_styles;

wp_enqueue_style($locale, content_url("languages/$locale.css"), array(), '20100615', 'all');
wp_enqueue_style("$locale-ie", content_url("languages/$locale-ie.css"), array(), '20100615', 'all');
if ( is_multisite() )
wp_enqueue_style("ms-$locale", content_url("languages/ms-$locale.css"), array(), '20100615', 'all');
$wp_styles->add_data("$locale-ie", 'conditional', 'IE');

wp_print_styles();
}
add_action('admin_head', 'ru_accomodate_markup');

function ru_populate_options() {
add_option('rss_language', 'ru');
}
add_action('populate_options', 'ru_populate_options');

function ru_restore_scripts_l10n() {
global $wp_scripts;

if ( is_a($wp_scripts, 'WP_Scripts') ) {
do_action_ref_array('wp_default_scripts', array(&$wp_scripts));
}
}
add_action('init', 'ru_restore_scripts_l10n');
?>

Патч:

--- ru_RU.php.orig 2010-12-01 14:01:46.000000000 +0200
+++ ru_RU.php 2010-12-01 14:59:25.000000000 +0200
@@ -5,10 +5,10 @@
function ru_accomodate_markup() {
global $locale, $wp_styles;

- wp_enqueue_style($locale, WP_CONTENT_URL . "/languages/$locale.css", array(), '20100615', 'all');
- wp_enqueue_style("$locale-ie", WP_CONTENT_URL . "/languages/$locale-ie.css", array(), '20100615', 'all');
+ wp_enqueue_style($locale, content_url("languages/$locale.css"), array(), '20100615', 'all');
+ wp_enqueue_style("$locale-ie", content_url("languages/$locale-ie.css"), array(), '20100615', 'all');
if ( is_multisite() )
- wp_enqueue_style("ms-$locale", WP_CONTENT_URL . "/languages/ms-$locale.css", array(), '20100615', 'all');
+ wp_enqueue_style("ms-$locale", content_url("languages/ms-$locale.css"), array(), '20100615', 'all');
$wp_styles->add_data("$locale-ie", 'conditional', 'IE');

wp_print_styles();

Интересно, кому об этой ошибке сообщать?

Очередная партия исправлений для Simple Tags

Vladimir — Thu, 28 Oct 2010 18:30:49 +0000

Cannot load st_mass_tags

Благодаря одному из своих читателей я узнал, что у плагина Simple Tags помимо проблем, которые я регулярно исправляю, есть еще одна: при попытке зайти в Posts » Mass edit terms » All Pages выдаётся сообщение Невозможно загрузить st_mass_tags.

Об ошибке автору сообщили на форуме поддержки, но так как автор в комментариях не отметился, пришлось исправлять плагин самостоятельно.

Как оказалось, всё дело в вызове add_posts_page(). Дело в том, что эта функция регистрирует страницу плагина в системе только для меню «Записи» (Posts). Ссылки «Все записи», «Черновики», «Опубликованные» работают нормально, так как в их основе /wp-admin/edit.php?page=st_mass_tags. А ссылка «Все страницы» (/wp-admin/edit.php?page=st_mass_tags&post_type=page) уже не работает — из-за post_type=page. А всё потому, что edit.php?post_type=page — это уже другое меню (Страницы/Pages), для которого add_posts_page() не работает. Для того, чтобы зарегистрировать страницу в этом меню, нужно использовать функцию add_pages_page().

Но при использовании add_pages_page() ссылка на страницу появится в меню «Страницы», а это, скорее всего, не совсем то, что хотел автор (фактически, у нас бы получилось два пункта «Mass Edit Terms» — один в меню записей, другой в меню страниц). Поэтому для чистого решения проблемы нужно проэмулировать работу функции add_pages_page(), но не создавать запись в меню.

Решение получается очень простым:

--- simple-tags/inc/admin.orig.php 2010-10-24 15:31:16.000000000 +0300
+++ simple-tags/inc/admin.php 2010-10-24 15:59:37.000000000 +0300
@@ -231,6 +231,17 @@
add_posts_page( __('Simple Terms: Mass Edit Terms', 'simpletags'), __('Mass Edit Terms', 'simpletags'), 'simple_tags', 'st_mass_tags', array(&$this, 'pageMassEditTags'));
add_posts_page( __('Simple Terms: Auto Terms', 'simpletags'), __('Auto Terms', 'simpletags'), 'simple_tags', 'st_auto', array(&$this, 'pageAutoTags'));
add_options_page( __('Simple Tags: Options', 'simpletags'), __('Simple Tags', 'simpletags'), 'admin_simple_tags', 'st_options', array(&$this, 'pageOptions'));
+
+ global $_registered_pages, $_wp_real_parent_file;
+ $menu_slug = plugin_basename('st_mass_tags');
+ $parent_slug = plugin_basename('edit.php?post_type=page');
+ if (isset($_wp_real_parent_file[$parent_slug])) {
+ $parent_slug = $_wp_real_parent_file[$parent_slug];
+ }
+
+ $hookname = get_plugin_page_hookname($menu_slug, $parent_slug);
+ add_action($hookname, array(&$this, 'pageMassEditTags'));
+ $_registered_pages[$hookname] = true;
}

/**

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

Устранена эта самая ошибка;
добавлена поддержка UTF-8 в автоматических ссылках;
оптимизирован вызов register_uninstall_hook();
исправлена проблема с локализацией (спасибо Analitik).

Скачать исправленный плагин Simple Tags 1.8.2.

Ошибка сборки модуля VMware vsock для ядра Linux 2.6.35

Vladimir — Thu, 14 Oct 2010 11:15:55 +0000

/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3233: error: ‘struct sock’ has no member named ‘sk_sleep’

При сборке модуля vsock VMware Player 3.x или VMware WorkStation 7.1 для ядра Linux 2.6.35 могут возникать подобные ошибки компиляции:

CC [M] /tmp/vmware-root/modules/vsock-only/linux/af_vsock.o
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c: In function ‘VSockVmciStreamConnect’:
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3233: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3256: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3268: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c: In function ‘VSockVmciAccept’:
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3328: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3344: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3378: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c: In function ‘VSockVmciPoll’:
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:3476: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c: In function ‘VSockVmciStreamSendmsg’:
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:4116: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:4153: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:4206: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c: In function ‘VSockVmciStreamRecvmsg’:
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:4440: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:4480: error: ‘struct sock’ has no member named ‘sk_sleep’
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:4546: error: ‘struct sock’ has no member named ‘sk_sleep’

Это не фатально, так как VMware может работать и без vsock, но при каждом запуске будет пересобирать и устанавливать модули заново. Неприятно, но лечится.

Проблема здесь в том, что в ядрах 2.6.35 в struct sock члена sk_sleep больше нет — вместо него используется sk_sleep().

Патч тривиален:

diff -uwdBrN vsock-only.orig/linux/af_vsock.c vsock-only/linux/af_vsock.c
--- vsock-only.orig/linux/af_vsock.c 2010-09-21 09:17:24.000000000 +0300
+++ vsock-only/linux/af_vsock.c 2010-10-08 01:18:09.193864493 +0300
@@ -3230,7 +3230,7 @@
* a notification of an error.
*/
timeout = sock_sndtimeo(sk, flags & O_NONBLOCK);
- compat_init_prepare_to_wait(sk->compat_sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ compat_init_prepare_to_wait(compat_sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);

while (sk->compat_sk_state != SS_CONNECTED && sk->compat_sk_err == 0) {
if (timeout == 0) {
@@ -3253,7 +3253,7 @@
goto outWaitError;
}

- compat_cont_prepare_to_wait(sk->compat_sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ compat_cont_prepare_to_wait(compat_sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
}

if (sk->compat_sk_err) {
@@ -3265,7 +3265,7 @@
}

outWait:
- compat_finish_wait(sk->compat_sk_sleep, &wait, TASK_RUNNING);
+ compat_finish_wait(compat_sk_sleep(sk), &wait, TASK_RUNNING);
out:
release_sock(sk);
return err;
@@ -3325,7 +3325,7 @@
* upon connection establishment.
*/
timeout = sock_sndtimeo(listener, flags & O_NONBLOCK);
- compat_init_prepare_to_wait(listener->compat_sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ compat_init_prepare_to_wait(compat_sk_sleep(listener), &wait, TASK_INTERRUPTIBLE);

while ((connected = VSockVmciDequeueAccept(listener)) == NULL &&
listener->compat_sk_err == 0) {
@@ -3341,7 +3341,7 @@
goto outWait;
}

- compat_cont_prepare_to_wait(listener->compat_sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ compat_cont_prepare_to_wait(compat_sk_sleep(listener), &wait, TASK_INTERRUPTIBLE);
}

if (listener->compat_sk_err) {
@@ -3375,7 +3375,7 @@
}

outWait:
- compat_finish_wait(listener->compat_sk_sleep, &wait, TASK_RUNNING);
+ compat_finish_wait(compat_sk_sleep(listener), &wait, TASK_RUNNING);
out:
release_sock(listener);
return err;
@@ -3473,7 +3473,7 @@
sk = sock->sk;
vsk = vsock_sk(sk);

- poll_wait(file, sk->compat_sk_sleep, wait);
+ poll_wait(file, compat_sk_sleep(sk), wait);
mask = 0;

if (sk->compat_sk_err) {
@@ -4113,7 +4113,7 @@
goto out;
}

- compat_init_prepare_to_wait(sk->compat_sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ compat_init_prepare_to_wait(compat_sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);

while (totalWritten < len) {
Bool sentWrote;
@@ -4150,7 +4150,7 @@
goto outWait;
}

- compat_cont_prepare_to_wait(sk->compat_sk_sleep,
+ compat_cont_prepare_to_wait(compat_sk_sleep(sk),
&wait, TASK_INTERRUPTIBLE);
}

@@ -4203,7 +4203,7 @@
if (totalWritten > 0) {
err = totalWritten;
}
- compat_finish_wait(sk->compat_sk_sleep, &wait, TASK_RUNNING);
+ compat_finish_wait(compat_sk_sleep(sk), &wait, TASK_RUNNING);
out:
release_sock(sk);
return err;
@@ -4437,7 +4437,7 @@
goto out;
}

- compat_init_prepare_to_wait(sk->compat_sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ compat_init_prepare_to_wait(compat_sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);

while ((ready = VSockVmciStreamHasData(vsk)) < target &&
sk->compat_sk_err == 0 &&
@@ -4477,7 +4477,7 @@
goto outWait;
}

- compat_cont_prepare_to_wait(sk->compat_sk_sleep, &wait, TASK_INTERRUPTIBLE);
+ compat_cont_prepare_to_wait(compat_sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
}

if (sk->compat_sk_err) {
@@ -4543,7 +4543,7 @@
err = copied;

outWait:
- compat_finish_wait(sk->compat_sk_sleep, &wait, TASK_RUNNING);
+ compat_finish_wait(compat_sk_sleep(sk), &wait, TASK_RUNNING);
out:
release_sock(sk);
return err;
diff -uwdBrN vsock-only.orig/shared/compat_sock.h vsock-only/shared/compat_sock.h
--- vsock-only.orig/shared/compat_sock.h 2010-09-21 09:17:22.000000000 +0300
+++ vsock-only/shared/compat_sock.h 2010-10-08 01:15:31.667045243 +0300
@@ -68,6 +68,10 @@
# define compat_sk_rcvtimeo sk_rcvtimeo
#endif

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 34)
+# undef compat_sk_sleep
+# define compat_sk_sleep(sk) sk_sleep(sk)
+#endif

/*
* Prior to 2.5.65, struct sock contained individual fields for certain

R1Soft CDP с ядром 2.6.35

Vladimir — Thu, 14 Oct 2010 10:15:18 +0000

Решение проблемы сборки модуля ядра для Linux kernel 2.6.35

При попытке собрать модуль под ядро Linux 2.6.35 r1soft-cki выдаёт примерно следующий текст:

Checking for binary module
Waiting |
No binary module found
Gathering kernel information
Gathering kernel information complete.
Creating kernel headers package
Checking '/tmp/r1soft-cki.1286865605' for kernel headers
Unable to find a 'include/linux/autoconf.h'. This file is required to build a kernel module
Unable to find a valid source directory.
Please install the kernel headers for your operating system.
To install kernel headers execute:
apt-get install linux-headers-`uname -r`

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

Проблема здесь в том, что в ядрах 2.6.35 autoconf.h находится совершенно в другом месте: в каталоге

/usr/src/linux-headers-`uname -r`/include/generated/

а не в каталоге

/usr/src/linux-headers-`uname -r`/include/linux/

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

Поэтому решение проблемы тривиально:

touch /usr/src/linux-headers-`uname -r`/include/linux/autoconf.h

После этого r1soft-cki успешно отправляет все данные на сервер и получает требуемый модуль ядра.