Попробуем организовать эмулятор для ARMv7 при помощи QEMU 4.20 и установим какой-нибудь Linux.

Для начала нам понадобится скачать так называемый netboot образ системы для armhf, состоящий из двух компонент: vmlinuz и initrd.gz. После ряда экспериментов выяснилось, что современные инсталляторы Ubuntu по умолчанию непригодны для этих целей, так что возьмем Debian Buster[1].

Подготовим файл образа “диска”, в который будем устанавливать систему:

qemu-img create -f qcow2 debian.qcow2 8G

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

Собираем файлы в одном месте и запускаем эмулятор со следующими параметрами:

qemu-system-arm -smp 4 -m 1024 -M virt \
   -kernel vmlinuz \
   -initrd initrd.gz \
   -append "root=/dev/ram" \
   -netdev user,id=n1
   -device virtio-net-device,netdev=n1 \
   -drive if=none,file=debian.img,format=qcow2,id=hd \
   -device virtio-blk-device,drive=hd \
   -no-reboot

Параметры:

• smp – количество ядер;
• m – объем памяти;
• M – тип машины, virt – абстрактно-виртуальный ARM;
• netdev – тип сети, user – самый простой вариант, не требующий настройки хост-машины;
• device virtio-net-device – устройство “сетевой карты”, и выбирать следует именно это, а не упомянутое в различных инструкциях, т.к. иначе с огромной вероятностью вы наткнетесь на сообщение о том, что инсталлятор системы не обнаружил никаких сетевых устройств в системе;
• drive if=none,file=debian.img,format=qcow2 – образ жесткого диска;
• device virtio-blk-device – устройство “жесткого диска”, аналогично сети, этот вариант обнаруживается установщиком, многие другие – нет;
• no-reboot – перезапуск системы приведет к остановке эмулятора.

Если запускаем qemu-system-arm в консоли без графического интерфейса, то дописываем “-nographic”.

Устанавливаем Debian как обычно. На количестве ядер не следует экономить, т.к. в процессе установки есть этапы, которые, по всей видимости, могут неплохо параллелиться, а однопоточная производительность эмулятора далека от производительности хост-машины: в среднем на установку системы уходило около часа на четырехъядерном Intel Xeon 3.5 GHz.

Ближе к концу установки инсталлятор ругнется на невозможность установки grub – так и должно быть в этом эмуляторе.

Далее, когда инсталлятор сообщит о завершении, выберите “Go back” и из главного меню установщика выберите пункт про вход в консоль. В консоли целевой диск, куда производилась установка, будет доступен по пути /target. Поскольку у эмулятора нет загрузчика, нам понадобится вытащить уже из установленной системы соответствующие ей vmlinuz и initrd.img. Для этого можно сделать chroot /target и, используя набор стандартных утилит – например, scp – откопировать файлы, находящиеся в /target/boot (а после chroot так просто в /boot) куда-нибудь вовне эмулятора. Если установленных утилит не хватает, то уже в chroot-е можно легко использовать apt и apt-get для установки недостающего. После копирования выходим из консоли и в меню инсталлятора выбираем пункт завершения установки. Когда установщик выполнит перезагрузку, эмулятор просто выключится согласно опции no-reboot.

Конечно, в качестве альтернативы можно вынуть vmlinuz и initrd из установленной системы и при помощи средств конвертации и распаковки qcow2 файлов – таких инструкций в интернете уйма. В этом случае прежде, чем что-то сделать с образом диска, не забывайте остановить эмулятор, чтобы не повредить образ.

Причина же, по которой изначально не удалось использовать современные образы Ubuntu, состоит в том, что в них после установки по малопонятной причине не генерируется файл initrd.img – в директории /target/boot есть битые симлинки на него, тогда как сам initrd отсутствует. [Update: Способ исправления был найден в комментариях на gist.github.com[2]]

Итак, после описанных действий у вас должен оказаться на руках образ debian.img с установленной ОС и файлы vmlinuz и initrd.img, взятые из этого же образа. Старые vmlinuz и initrd.gz с netboot-инсталлятором можно удалить – они больше не понадобятся. Теперь для запуска системы нужно переписать аргументы qemu-system-arm на следующие:

qemu-system-arm -smp 4 -m 1024 -M virt \
   -kernel vmlinuz \
   -initrd initrd.img \
   -append "root=/dev/vda2" \
   -netdev user,id=n1
   -device virtio-net-device,netdev=n1 \
   -drive if=none,file=debian.img,format=qcow2,id=hd \
   -device virtio-blk-device,drive=hd \
   -no-reboot

Вот, в общем-то, и всё.

Для того, чтобы зайти извне в такую гостевую машину по SSH, можно заменить -netdev user,id=n1 на -netdev user,hostfwd=tcp::10022-:22,id=n1, и тогда при подключении к порту 10022 на хост-машине соединение будет перенаправлено на 22 порт гостевой машины. Либо воспользоваться ssh-туннелем, подняв из гостевой машины подключение к удаленному ssh-серверу с дополнительным параметром -R 10022:localhost:22 – в этом случае порт 10022 на удаленном сервере будет перенаправлен на порт 22 гостевой машины.

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

После изучения означенного вопроса оказалось, что суть проблемы сводится к битриксовому API CIBlockElement::GetList() и соответствующему ему GetNext(), которые при некоторых условиях переставали высвобождать память после каждого своего вызова. Очевидно, что после попытки выполнения их по нескольку десятков тысяч раз внутри одного скрипта (который по расписанию перегенерирует карту сайта), разрешенный объем памяти в PHP довольно быстро заканчивался.

Тот факт, что ранее тот же самый код работал без подобных проблем, со временем вывел расследование на opcache, а конкретно – к оптимизации ZEND_OPTIMIZER_PASS_6 (1<<5) /* DFA based optimization */. По счастью, настройки opcache позволяют выбирать активные оптимизации и отключать те, что могут вызывать проблемы. Соответственно, в конфигурацию была добавлена следующая опция, отключающая только проблемную оптимизацию и оставляющая все остальные:

opcache.optimization_level=0x7FFEBFDF

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

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

#define ZEND_OPTIMIZER_PASS_1		(1<<0)   /* CSE, STRING construction     */
#define ZEND_OPTIMIZER_PASS_2		(1<<1)   /* Constant conversion and jumps */
#define ZEND_OPTIMIZER_PASS_3		(1<<2)   /* ++, +=, series of jumps      */
#define ZEND_OPTIMIZER_PASS_4		(1<<3)   /* INIT_FCALL_BY_NAME -> DO_FCALL */
#define ZEND_OPTIMIZER_PASS_5		(1<<4)   /* CFG based optimization       */
#define ZEND_OPTIMIZER_PASS_6		(1<<5)   /* DFA based optimization       */
#define ZEND_OPTIMIZER_PASS_7		(1<<6)   /* CALL GRAPH optimization      */
#define ZEND_OPTIMIZER_PASS_8		(1<<7)   /* SCCP (constant propagation)  */
#define ZEND_OPTIMIZER_PASS_9		(1<<8)   /* TMP VAR usage                */
#define ZEND_OPTIMIZER_PASS_10		(1<<9)   /* NOP removal                 */
#define ZEND_OPTIMIZER_PASS_11		(1<<10)  /* Merge equal constants       */
#define ZEND_OPTIMIZER_PASS_12		(1<<11)  /* Adjust used stack           */
#define ZEND_OPTIMIZER_PASS_13		(1<<12)  /* Remove unused variables     */
#define ZEND_OPTIMIZER_PASS_14		(1<<13)  /* DCE (dead code elimination) */
#define ZEND_OPTIMIZER_PASS_15		(1<<14)  /* (unsafe) Collect constants */
#define ZEND_OPTIMIZER_PASS_16		(1<<15)  /* Inline functions */

#define ZEND_OPTIMIZER_IGNORE_OVERLOADING	(1<<16)  /* (unsafe) Ignore possibility of operator overloading */

PS: Всё это не было бы особо мозголомно, если бы не тот факт, что вся эта проблема наблюдалась на одном сайте и не наблюдалась на другом – в разных пулах PHP-FPM в рамках одного и того же сервера. Объяснение тому оказалось прямолинейным: там, где проблема не наблюдалась, opcache отчего-то не функционировал. Нет, не был выключен в настройках – он был включен, но просто перестал работать. После перезапуска FPM проблема начала одинаково воспроизводиться на обоих сайтах. Впоследствии, к слову, это же вынудило переустановить PHP из репозитория Remi, раз в официальном и версия PHP получала лишь обновления безопасности к старому релизу, а не обновления к более новым, и происходили подобные вещи. К сожалению, начальную проблему с DFA это обновление не исправило.

Наглядный пример – RHEL8. Для чистого iptables и аналогов есть модули nf_conntrack_helper и, в частности, nf_conntrack_ftp. Интернет подсказывает, что в ядрах версии 4.7 и выше они по умолчанию отключены и требуют или ручного включения, или отдельной маркировки соединений. Но вот только у RHEL8 предлагается использовать надстройку FirewallD, мануал которого ещё в 2016 году упоминал автоматическое использование соответствующего helper-а, если в конфигурации файрвола активирован стандартный сервис ftp, открывающий доступ к 21-му порту. Так, утверждается, что в выбранном по умолчанию режиме AutomaticHelpers = system должно проверяться значение /proc/sys/net/netfilter/nf_conntrack_helper (которое в >4.7 выключено) и, в зависимости от него, будут предприниматься необходимые меры для автоматического открывания портов для передачи данных через FTP. Но проблема в том, что этого не происходит.

Практический же опыт показывает, что помимо активации в файрволе сервиса ftp всё же необходимо в firewalld.conf дописать AutomaticHelpers = on, после чего никаких отдельных настроек портов для passive mode FTP не понадобится. Отчего это не работает в режиме system в релизной версии RHEL8 – неизвестно.

Вот только при запуске успешно собранного бинарника можно увидеть ошибку pdns_server: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26′ not found (required by pdns_server)

Она говорит о том, что указанная библиотека ни черта не прилинковалась статически.

Заставить ее это сделать можно дописыванием LDFLAGS перед запуском ./configure:

LDFLAGS="-static-libstdc++" ./configure --with-modules="gmysql" --without-lua --enable-static --enable-static-boost --prefix=/

Это отвяжет зависимость от версии libstdc++ на целевой машине.

Говорят, для другого софта может пригодиться вбивание -static-libgcc, если он собирается CC, а общий -static попытается собрать всё остальное статически.

А так-то понятно, что лучше не собирать на коленке вручную, а использовать готовые пакеты требуемого софта для имеющейся операционной системы. Когда они есть в природе. Правда ведь, RHEL8?

Связано это с использованием любыми официальными клиентами (в т.ч. веб-интерфейсом) “обновленного” протокола ICQ, в котором клиент считается всегда находящимся в как-бы-в-сети, а также при подключении предполагает, что настоящий клиент самостоятельно запросит непрочтенные оффлайновые сообщения, висящие на псевдоонлайновом статусе, а не будет ждать, пока в него их насильно запихнут.

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

1. Добавляем в контакты бота по имени aolsystemmsg;
2. Отправляем ему единицу – 1.

Это разлогинит все имеющиеся сессии, включая псевдоонлайновые, кроме текущей. Если после этого заходить в ICQ только со старых клиентов, то они будут вполне корректно получать оффлайновые сообщения. Естественно, любой заход через современный официальный клиент приведет к тому, что его сессия после выхода останется висеть “в сети” и потребует нового сброса псевдоонлайновых сессий.

ЗЫ: А почему это до сих пор не исправят разработчики сторонних клиентов – так, похоже, никому это уже и не нужно.
ЗЗЫ: Бот отвечает ещё до отправки вашего запроса. Машины времени и всё такое, да.

Оформление заявки на сайте

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

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

Оформление заявки менеджером

Описав менеджеру необходимые условия подключения, тот перепроверил адрес и заявил, что там подключение возможно только по коаксиальному кабелю, стоить будет в полтора раза дороже, а ещё и модем нужно будет брать в аренду. И никакой витой пары в моем доме нет и быть не может. “Точно?” “Точно!”

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

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

Ограничь всё, или как вытрясти денег

По умолчанию этот провайдер подключает абонентов на приватные адреса из диапазона 10.0.0.0/8. А шел 2018 год. А про внешнюю динамику никто никогда и не слышал. Ну ладно, зато вдвое дешевле, причем за чуть более высокую скорость.

Но это не всё. Про DHCP и автоматическую раздачу сетевых настроек в этой сети тоже не слышали, поэтому при подключении на руки выдается листочек с параметрами сети. DNS-серверов в нем перечислено целых 4 штуки, и, похоже, не зря в интернете пишут, что они периодически падают (или падали в прошлом?). Но, казалось бы, зачем нам это – в интернете есть масса беспроблемных DNS-ок, можно просто пользоваться ими. Верно же? Неверно. Обращения ко внешним DNS-ам порезаны напрочь. Ну, вот просто так. И про GRE тоже можно не вспоминать.

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

Приобретение статики

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

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

Тайна настроек, да и остальной набор тайн

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

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

Доверяй, но проверяй. Нет, просто проверяй

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

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

Резюме

В общих чертах, оно работает. Просто на некоторые вещи лучше закрыть глаза.

Симптомы: на виндовых машинах подключение к VPN виснет на “проверке имени пользователя и пароля”, затем выдается ошибка 619. В логах PPTP-сервера видно, что он не получает отклика от клиента и сбрасывает подключение по таймауту, а в трафике видны только исходящие GRE-пакеты в сторону PPTP-клиента. На NAT-шлюзе в трафике при этом присутствуют и входящие, и исходящие GRE-запросы.

Спустя время было выявлено, что затык именно на стороне клиента, а именно на NAT-шлюзе: для работы PPTP на нем нужно подгрузить следующие модули (для CentOS):

modprobe ip_nat_pptp
modprobe ip_conntrack_pptp
modprobe ip_gre

Несмотря на то, что, казалось бы, каких-либо открываний портов, или разрешений протоколов в файрволе, или других настроек на NAT-шлюзе для использования на стоящих за ним компьютерах PPTP-клиента не требуется, все-таки кое-что сделать придется. Так как с настройками по умолчанию (по крайней мере, для CentOS 6) GRE-трафик пропускаться не будет.

Хотя relay-функциональность icecast и позволяет разбирать этот код и реагировать на него соответствующим образом, работает это не всегда.

Можно столкнуться со следующей ситуацией: головной source-сервер перегружен и выдает редиректы на дополнительные серверы, при проверке браузером все корректно, но наш icecast-ретранслятор их будто “не замечает” и выдает клиентам ошибку 404. В логах нашего icecast’а при этом можно увидеть следующие записи:

[2015-09-25  10:58:40] INFO slave/start_relay_stream Starting relayed source at mountpoint "/<mountname>"
[2015-09-25  10:58:40] INFO slave/open_relay_connection connecting to <main.source>:80
[2015-09-25  10:58:40] INFO slave/open_relay_connection redirect received HTTP://<fallback.source>

После этого клиенту выдается ошибка 404 и более ничего содержательного в лог не попадает. Так в чем же дело?

В исходном коде icecast можно найти следующие строки:

            ICECAST_LOG_INFO("redirect received %s", uri);
            if (strncmp (uri, "http://", 7) != 0)
                break;

Так выясняется, что если полученная ссылка из 302-го редиректа не начинается на “http://” (в НИЖНЕМ регистре!), то наш icecast с ней не будет делать вообще ничего и сделает вид, что никакого редиректа не было. А как видно из лога, наш источник рассылает редиректы, начинающиеся на HTTP:// в верхнем регистре.

Очевидно, надо научить icecast не обращать внимание на разницу регистров в протоколе. Это можно сделать разными способами, оптимальность и красота которых зависит от качества вашего владения кунг-фу Си. Можно, например, сделать как-то так:

--- icecast-2.4.2/src/slave.c   2015-04-08 11:06:13.000000000 +0300
+++ icecast-2.4.2-mod/src/slave.c       2015-09-25 10:55:29.495738535 +0300
@@ -238,13 +238,19 @@
         if (strcmp (httpp_getvar (parser, HTTPP_VAR_ERROR_CODE), "302") == 0)
         {
             /* better retry the connection again but with different details */
-            const char *uri, *mountpoint;
-            int len;
+            const char *uri, *mountpoint, *proc = "http://";
+            int i, len;

             uri = httpp_getvar (parser, "location");
+
             ICECAST_LOG_INFO("redirect received %s", uri);
-            if (strncmp (uri, "http://", 7) != 0)
-                break;
+            for (i = 0; i < 7 && uri[i]; i++) {
+                if ((tolower(uri[i]) - tolower(proc[i])) != 0) {
+                    i = 10;
+                    break;
+                }
+            }
+            if (i == 10) break;
             uri += 7;
             mountpoint = strchr (uri, '/');
             free (mount);

Пересобираем, подключаемся, смотрим лог:

[2015-09-25  11:08:40] INFO slave/start_relay_stream Starting relayed source at mountpoint "/<mountname>"
[2015-09-25  11:08:40] INFO slave/open_relay_connection connecting to <main.source>:80
[2015-09-25  11:08:40] INFO slave/open_relay_connection redirect received HTTP://<fallback.source>
[2015-09-25  11:08:40] INFO slave/open_relay_connection connecting to <fallback.source>:80
[2015-09-25  11:08:40] WARN format/format_get_type Unsupported or legacy stream type: "audio/mpeg". Falling back to generic minimal handler for best effort.
[2015-09-25  11:08:40] INFO source/source_main listener count on /<mountname> now 1

И все работает.

Проблема проявляется в виду того, что FF использует гугловскую базу ненадежных сайтов, которая запросто может ошибаться. Что любопытно – в Google Chrome применяется иной реестр вредоносных сайтов, и зачастую то, что [ошибочно] заблокировано в FF, успешно открывается в Хроме.

Так или иначе, но с проблемой нужно бороться – достаточно того, что наше любимое правительство решает, какие сайты нам смотреть можно, а какие – нельзя. Не хватало еще, чтобы и браузер начал указывать, что какой-нибудь архив или документ к скачиванию недопустим, а, следовательно, пожелавший его скачать пользователь может идти лесом (в другой браузер). И всё – из-за того, что разработчики FF не соизволили добавить кнопку одноразового обхода блокировки. Нет, такие удобства нам не нужны.

По счастью, выключать одним махом все проверки вредоносных сайтов не потребуется. Для решения проблемы нужно открыть страницу настроек – about:config, и переключить параметр browser.safebrowsing.downloads.enabled в положение false. Теперь FF позволит скачивать любые файлы.

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

Разгадка кроется в малозаметном патче к libiconv-full под названием 100-strip-charsets.patch. Пролистав его можно с удивлением обнаружить, что пакет, вроде бы имеющий в названии слово “full”, ничего общего с этим словом не имеет: доблестные разработчики OpenWrt в “полной” версии libiconv просто выпилили 97% всех кодировок, включая все упоминания кириллических, и оставив лишь несколько западноевропейских.

Наиболее простое решение – просто удалить патч 100-strip-charsets.patch из пакета libiconv-full. Но так размер данной библиотеки увеличится в несколько раз! По этой причине мы сделали исправленную версию исходного патча, в которой оставлены кириллические кодировки, но вырезано большинство прочих.

Скачать исходный код модифицированного libiconv-full можно из нашего архива.