! страницы почты
mail.yandex.ru##div[data-testid="page-layout_right-column_container_v1"], div[data-testid="content-header_container"] > div:not([data-testid="toolbar-layout_container"]), div.Modal.Modal_visible[class*="Fullscreen_root_"]

! страница погоды
yandex.ru##div[class*="AppLayoutTypeMain_centerWrapper_"] aside[class*="AppLayoutTypeMain_right_"], [class*="MainPage_topBlockWithMoney_"], [class*="AppForecastMoney_wrap_"], [class*="Money_ecomFooter_"], [class*="AppMoney_wrap_"], [class*="AppPromoInner_container_"]

! страница поиска
ya.ru##div[class*="body_"] > aside ~ div, .Distribution, #search-result-aside

Реклама на тот момент выглядела как отдельная строчка в перечне писем + три огромных графических баннера по левой стороне экрана, под категориями (в прошлом, насколько вспоминается, там были 2-3 баннера суммарного размера как один нынешний). Разумеется, опция отключения рекламы из настроек почты безвозвратно исчезла. Помимо этого, что характерно, обнаружилось, что на паре других яндекс.учеток никакого предложения покупки “про-версии” почты нет, как нет и рекламы. Update: спустя некоторое время она появилась и там тоже.

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

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

mail.yandex.ru##.mail-Layout-Content > .ns-view-advanced-search-box + div, .mail-Layout-Aside-Inner > .ns-view-left-box .qa-LeftColumn > div:last-Child, .mail-Layout-Aside-Inner > .ns-view-left-box .ns-view-react-left-column + div, .tooltip_theme_promo, .pushPromo

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

yandex.ru##.distr-promo-head, .distr-popup, .dist-popup, .bottom-popup, .serp-footer_type_distro, .distr-smartbanner-loader
yandex.ru##.advert, .b-statcounter + div, #bk-stripe

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

PS: Яндекс.новации последнее время, кажется, падают все ниже и ниже. Когда-то давно они сделали сервис почты-для-домена, включая днс-хостинг, и у него был какой-никакой API для автоматического управления (читай – DDNS). Затем его “проапгрейдили” до яндекс.коннекта, без предупреждений снеся старое API, но так и не сделав новое на замену. Теперь вот игры в какие-то “прошечки” в попытке сделать платным то, что вот только вчера было полностью бесплатным, но при этом представить всё это так, как будто в этом есть что-то новое и новаторское. Куда еще смогут упасть?

Заведение IP:

ifconfig eth0:1 <ip-address> netmask <netmask> up

Если это роутер с NAT или просто нужна возможность организовать внешние соединения с этого IP (а не на него), то требуется новая таблица в /etc/iproute2/rt_tables. Далее:

ip route add <network>/29 dev eth0:1 src <ip-address> table <table>
ip route add default via <network gateway> table <table>
ip route add 192.168.0.0/24 dev eth1 table <table>
ip rule add from <network> table <table>

Посмотреть, что получилось:

ip rule show
ip route list table <table>

Задать маршруты по умолчанию тем же ip route, но без table. Правила iptables для NAT типовые.

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

Симптомы: на виндовых машинах подключение к 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 можно из нашего архива.

Как оказалось, эта проблема имеет простое решение.

Логирование в davfs2, размещенном на роутере под управлением OpenWrt, организовано не самым удобным образом. Лог всегда пишется в системный кольцевой буфер, прочитать который можно при помощи команды logread, и объем оного весьма незначителен. А отладочные сообщения davfs2 в зависимости от выбранного уровня отладки либо слишком подробны и многочисленны, либо слишком кратки и по ним ничего невозможно понять.

Так или иначе, при работе стандартного пакета davfs2 с выставленным в davfs2.conf параметре debug most в системном логе можно наблюдать следующие строки при попытке загрузки файла в удаленное хранилище:

Mon Dec 22 19:15:36 2014 mark.debug syslog: Running pre_send hooks
Mon Dec 22 19:15:36 2014 mark.debug syslog: Sending request headers:
Mon Dec 22 19:15:36 2014 mark.debug syslog: PUT /testfile HTTP/1.1
User-Agent: davfs2/1.5.2 neon/0.30.0
Connection: TE
TE: trailers
Host: webdav.yandex.ru
Transfer-Encoding: chunked
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Mon Dec 22 19:15:36 2014 mark.debug syslog: Sending request-line and headers:
Mon Dec 22 19:15:36 2014 mark.debug syslog: Sending request body:
Mon Dec 22 19:15:36 2014 mark.debug syslog: Request body provider failed with 
Mon Dec 22 19:15:36 2014 mark.debug syslog: -
Mon Dec 22 19:15:36 2014 mark.debug syslog: 1
Mon Dec 22 19:15:36 2014 mark.debug syslog: 
Mon Dec 22 19:15:36 2014 mark.debug syslog: sess: Closing connection.
Mon Dec 22 19:15:36 2014 mark.debug syslog: sess: Connection closed.
Mon Dec 22 19:15:36 2014 mark.debug syslog: Request ends, status 
Mon Dec 22 19:15:36 2014 mark.debug syslog: 0
Mon Dec 22 19:15:36 2014 mark.debug syslog:  class 
Mon Dec 22 19:15:36 2014 mark.debug syslog: 0
Mon Dec 22 19:15:36 2014 mark.debug syslog: xx, error line:
Mon Dec 22 19:15:36 2014 mark.debug syslog: Failed reading request body file: Bad address
Mon Dec 22 19:15:36 2014 mark.debug syslog: 
Mon Dec 22 19:15:36 2014 mark.debug syslog: Running destroy hooks.
Mon Dec 22 19:15:36 2014 mark.debug syslog: Request ends.
Mon Dec 22 19:15:36 2014 mark.debug syslog: tidy: neon error
Mon Dec 22 19:15:36 2014 mark.debug syslog:       Failed reading request body file: Bad address

Как видим, выводится не самая информативная ошибка Bad address, происходящая из используемой в davfs2 для коммуникации библиотеки neon – текста Failed reading request body file в исходных кодах davfs2 найти не получится.

После некоторой изыскательной деятельности удалось обнаружить, что причина кроется в том простом факте, что библиотека neon и пакет davfs2 по умолчанию компилируются с разными параметрами. Так, в Makefile пакета neon указаны следующие флаги:

TARGET_CPPFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE

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

PS: Кстати, интересно отметить, что данная проблема не была зафиксирована в устаревшей версии davfs2, размещенной в нашем архиве – в нашем случае Makefile содержал все необходимые флаги для корректной сборки. Вопрос, отчего требуемые флаги потерялись в Makefile из официального репозитория OpenWrt, оставим на совести его мейнтейнеров. Да, кстати, версия davfs2 в нашем хранилище теперь обновлена до актуальной 1.5.2. А также приложен дополнительный патч, корректирующий вывод отладочного текста в системный лог.

Может возникнуть закономерный вопрос: зачем изобретать велосипед и почему бы не использовать обычный rsync для копирования данных напрямую в davfs2? Ответ простой: это… не работает как надо. Во всяком случае, с Яндекс.Диском, и если запускать процедуру на роутере под управлением OpenWrt.

То ли из-за особой неторопливости Яндекс.Диска, то ли из-за особенностей davfs2, но при попытке копирования большого количества файлов (а иногда такое случается и с единичными файлами!), большая их часть оказывалась в каталоге lost+found, служащем для локальных копий файлов, загрузка которых в WebDav провалилась. И всё это несмотря на достаточный объем выделенного кэша, стандартные настройки davfs2 для повторной загрузки файлов в случае ее неудачи, и довольно широкого канала связи.

Итак, для самописного и более надежного бэкапера в WebDav нам понадобятся:

1. davfs2 – стандартный пакет из репозитория OpenWrt;
2. cadaver – модифицированная версия утилиты для прямого копирования файлов в WebDav из нашего архива;
3. php-cli – стандартный интерпретатор PHP, при помощи которого мы сгенерируем набор команд для cadaver’а.

Добавленные в cadaver патчи позволяют при помощи нового ключа -F пропускать проверку подлинности сертификатов (а под OpenWrt у нас все используемые в WebDav SSL-сертификаты считаются подозрительными и требуют ручного подтверждения), а также указывать с помощью ключа -n нестандартный путь к хранилищу паролей для автоматической авторизации на WebDav-сервере. Внесенные изменения позволяют создать для cadaver файл с набором команд, которые будут выполняться автоматически без участия человека.

Теперь обратим внимание на скрипт phpsync.php.

У этого скрипта две задачи:
Во-первых, он отвечает за “обратную синхронизацию” – в скрипте производится проверка, все ли находящиеся в WebDav-хранилище файлы продолжают находиться на локальном диске. В случае обнаружения в удаленном хранилище файлов, которые были локально удалены, скрипт удалит их и из WebDav – обычным вызовом unlink() на смонтированном разделе davfs2.
Во-вторых, скрипт генерирует набор команд для cadaver‘а для загрузки локально измененных или отсутствующих в WebDav файлов в удаленное хранилище.
В скрипте есть ряд параметров, которые нужно настроить. Так, параметром $outfile определяется путь к файлу, в который будет записан сгенерированный набор команд, в параметре $remotebase необходимо указать точку монтирования davfs2. Также в нем указывается адрес WebDav сервера, к которому должен подключаться cadaver – по умолчанию это https://webdav.yandex.ru. Затем следует указать каталоги, которые требуется синхронизировать, например:

phpsync("/srv/content","/backup/content");
phpsync("/srv/otherdir","/backup/otherdir");

Так будут сгенерирован набор команд для отражения локальных каталогов /srv/content и /srv/otherdir в удаленные WebDav-каталоги /backup/content и /backup/otherdir соответственно. Обратите внимание – удаленные пути указываются относительно корня WebDav-диска, без привязки к локальной точке монтирования davfs2!

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

machine webdav.yandex.ru login вашлогин password вашпароль

Наконец, создаем ash-скрипт, который мы будем вызывать через кронтаб:

#!/bin/ash
/usr/bin/php-cgi -f /srv/phpsync.php

if [ -e "/var/.phpsync.list" -a $(wc -l "/var/.phpsync.list" | awk '{print $1;}') -gt 2 ]
then
        /usr/bin/cadaver -F -r "/var/.phpsync.list" -n "/srv/auth.rc"
fi

Подставляем ваши значения:

• /srv/phpsync.php — путь к PHP-скрипту;
• /srv/auth.rc — путь к парольному файлу;
• /var/.phpsync.list — путь к файлу с набором команд для cadaver.

Не забываем сделать скрипт исполняемым, выполнив команду chmod +x на данном файле. Теперь мы можем проверить работоспособность копирования, запустив этот скрипт. В терминал при этом будет выведен результат работы PHP-генератора, а также будет показан процесс выполнения задания cadaver’ом.

Если все завершилось успешно – теперь можем добавить автоматический вызов данного скрипта через кронтаб в ночное время и более не беспокоиться о создании резервных копий.

Давным-давно, в далекой-далекой галактике… оказалось, что много лет назад некий товарищ по имени ioannis в рамках решения означенной проблемы создал небольшое расширение SQLite, по сути представляющее собой урезанную версию ICU, из которой был выброшен код, который в 95% случаев никогда не потребуется. Таким образом удалось сократить размер расширения с мегабайт до символических 70-90 кбайт (в зависимости от архитектуры и компилятора). Копия исходного сообщения осталась доступна на mail-archive.com, и хотя оригинальная ссылка на исходный код расширения sqlite3_unicode.c неработоспособна, его все еще можно найти в интернете, а также мы добавили его в наш архив.

Возможности расширения

#define SQLITE3_UNICODE_FOLD – поддержка нелатинских символов функцией FOLD() – +10КБ
#define SQLITE3_UNICODE_LOWER – поддержка нелатинских символов функцией LOWER() – +10КБ
#define SQLITE3_UNICODE_UPPER – поддержка нелатинских символов функцией UPPER() – +10КБ
#define SQLITE3_UNICODE_TITLE – поддержка нелатинских символов функцией TITLE() – +10КБ
#define SQLITE3_UNICODE_UNACC – преобразование accented-символов в обычные, для русского языка не очень актуально – +30КБ
#define SQLITE3_UNICODE_COLLATE – заменяет COLLATION типа NOCASE на новый, в котором при сравнении не учитывается регистр в т.ч. и для нелатинских символов.
#define SQLITE3_UNICODE_UNACC_AUTOMATIC – попытаться применять UNACC в функции LIKE и операциях сравнения с COLLATE NOCASE.

Что характерно, функциональность, которая не требуется, может быть отключена путем убирания соответствующих #define для экономии места и увеличения производительности (вряд ли, впрочем, существенного).

Теперь разберемся, как собрать это расширение и задействовать его в cli-версии SQLite и в модуле для PHP.

Сборка под Linux

Для начала, скачиваем и распаковываем исходный код SQLite – нам потребуются заголовочные файлы из него. Можно использовать любую версию: я брал amalgamation без autoconf – она меньше. В тот же каталог копируем sqlite3_unicode.c.

Далее, корректности ради, открываем sqlite3_unicode.c текстовым редактором и вписываем вверху директиву:

/* we want shared library. only. */
#define SQLITE_ENABLE_UNICODE 1

Этим мы указываем, что собираемся компилировать shared-библиотеку. С другой стороны – соответствующий #if в коде расширения написан таким своеобразным образом, что этого можно и не делать.

Затем следует непосредственно процесс компиляции. Предполагается, что пакеты из набора build-essentials уже установлены в системе – во всяком случае, здесь потребуется gcc:

gcc -shared -o sqlite3_unicode.so sqlite3_unicode.c

Закрывая глаза на ряд warning’ов, получаем готовую библиотеку.

При работе с cli-версией потребуется разместить полученный sqlite3_unicode.so в каталоге с остальными системными библиотеками, либо же выполнить export следующего вида:

export LD_LIBRARY_PATH="/path/to/library/dir:$LD_LIBRARY_PATH"

Затем открываем cli и пишем команду .load sqlite3_unicode. Если ошибок не возникло – значит, расширение успешно загрузилось.

Для загрузки расширения в PHP потребуется в php.ini выставить корректный путь к месту расположения библиотеки в перараметре sqlite3.extension_dir. Затем в скрипте используем команду вида $db->loadExtension(‘sqlite3_unicode.so’);

Вот и всё – теперь сравнения с COLLATE NOCASE будут регистронезависимыми не только для латиницы, но и для русских букв.

Сборка под OpenWrt

Теперь попробуем побороть Buildroot от OpenWrt и кросс-компилировать это расширение в toolchain’е для запуска на роутере. В конечном счете, именно ради этого весь процесс и затевался – на ПК-то нет проблемы установить ICU, в отличие от встраиваемых систем. Надо признать, что борьба с Buildroot’ом для меня оказалась намного сложнее, чем все поиски решения проблемы с регистрозависимостью в целом и попытки разобраться, как его собирать в обычных условиях, в частности.

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

Его можно распаковать в каталог “package” корневой директории Buildroot’а, а затем нужно в make menuconfig выбрать пакет libsqlite3_unicode и запустить его сборку при помощи команды make package/libsqlite3_unicode/compile.

После установки полученного ipk на роутер подключение данного расширения производится аналогичным ранее описанному способом. Обратите внимание, что имя расширения для OpenWrt – libsqlite3_unicode.so, его размещение по умолчанию – /usr/lib.

Альтернативой davfs2 для прямого получения или загрузки файлов в облачное хранилище является утилита cadaver. Однако, она предполагает интерактивное взаимодействие с пользователем, и использование ее в автоматизированных скриптах не представляется возможным. Обойти эту проблему можно при помощи утилиты empty, аналога expect для создания и взаимодействия с псевдотерминалами.

Для реализации полностью автоматической загрузки и скачивания файлов с облачного хранилища был создан скрипт webdav.sh.

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

• ififo=/tmp/empty.in.fifo
  – путь к fifo ввода, на роутерах желательно размещать в /tmp
• ofifo=/tmp/empty.out.fifo
  – путь к fifo вывода, на роутерах желательно размещать в /tmp
• cmd=”cadaver https://webdav.yandex.ru”
  – путь к утилите cadaver и адрес WebDav-сервиса
• username=YourUserName
  – логин от WebDav-сервиса
• password=YourPassword
  – пароль от WebDav-сервиса

Доступные команды:

• webdav.sh put <локальный файл> [удаленный путь] – загрузка файла в облако
  – Локальный файл – обязательный параметр, должен быть указан один, файл должен быть доступен для чтения;
  – Удаленный путь – опционально, если его не указать, то файл будет загружен в корневой каталог WebDav.
• webdav.sh get <удаленный файл> [локальный путь] – выгрузка файла из облака
  – Удаленный файл – обязательный параметр, должен быть указан один, файл должен существовать;
  – Локальный путь – опционально, если его не указать, то файл будет загружены в текущий каталог.
• webdav.sh mput <локальные файлы> [удаленный путь] – множественная загрузка
  – Локальные файлы – маска вида “/path/to/*.files”, указание кавычек обязательно;
  – Удаленный путь – опционально, если его не указать, то файлы будут загружены в корневой каталог WebDav.
• webdav.sh mget <удаленные файлы> [локальный путь] – множественная выгрузка
  – Удаленные файлы – маска вида “/remote/path/*”;
  – Локальный путь – опционально, если его не указать, то файлы будут загружены в текущий каталог.

Например, для загрузки файла “/etc/config/firewall” в удаленный каталог “/openwrt” необходимо набрать команду webdav.sh put /etc/config/firewall /openwrt/firewall. Отметим, что удаленный каталог “openwrt” перед выполнением этой команды должен существовать.

PS: Стоит обратить внимание, что утилита empty имеет такую особенность, что если указанные в конфигурации fifo-файлы уже существуют на момент ее запуска, то она просто не запустится, тихо ругнувшись в syslog. А в случае каких-либо сбоев в ходе работы с empty эти fifo-файлы могут автоматически не удалиться.