crower: (Default)
2017-08-05 11:55 am
Entry tags:

И снова systemd

Рано радовался.
Как там система умудрилась пару раз подняться без даунгредового статуса не знаю, но после этого два раза подряд загружается с проблемами. Как всегда, с networking.service. И transmission-daemon не запускает.
Это хорошо, что я стат-робота научил мне сразу писать xmpp, так что практически сразу после перезагрузки получаю сообщение "не могу подключиться".
При этом нигде никаких следов не нашёл, почему такая замечательная systemd не захотела transmission загружать. Вроде зависимостей не много: privoxy, tor и dsncrypt-proxy. Все работают. Тут на днях, кстати, последние два как-то молча отваливались. Хорошо я как раз рядом был и быстро заметил — что-то не так, ну и знаю куда надо смотреть для начала. Даже подумал было что провайдер устроил атаку на "средства обхода". Но, слава Ктулху, нет — перезагрузил одно, другое и всё поехало дальше.
Сейчас тоже поглядел — networking как обычно со статусом failed. В логах eth1 поднимался нехорошо ("я уже поднялся, нехрен меня дёргать") и в ifstate его нет. Тупо зачем-то вписал, как и в прошлый раз. Другие-же вписаны - eth0 и lo. Но эту хрень не обманешь. При этом всё работает. Для профилактики systemctl start networking снова сделал. Обычно поднимается уже без failed, хотя кое-каких демонов система и дёргает зачем-то. В этот раз тоже пониженный статус ушёл, но какие-то странности стали наблюдаться. Трансмишин странно себя повёл - говорил что трафик есть, но не могут же цифры стоять как вкопаные. Рестартанул.
Пнул tor. Вроде активность появилась.
Глянул интерфейсы — а teredo-то и нету. Он тут, конечно, погоды не делает, но если поставили, то должон работать. Даю start - не работает. Ещё раз - хрен. Тогда сначала кладу: stop, start - поднялся мгновенно. Не иначе лежал, но pid остался и система считала что он работает. А раз работает, то нефиг трогать. Такой болезнью, кстати, страдает ntpd. Просишь ntpq время - а в ответ "Connection refused". В systemctl он зелёный, status=0/SUCCESS, active, но при этом exited. А он, оказывается не осчастливлен systemd. Надо посмотреть как его настроить чтобы автоматом перезапускался. Это, наверно, потому что они какой-то свой синхронизатор времени придумали.
Посмотрел логи - слишком быстро ntp поднимается и не может отресолвить нужные опорные сервера.

Борьба продолжается. :)
crower: (Default)
2017-07-25 12:07 pm
Entry tags:

transmission и профдеформация

Давно уже поглядывал на transmission, статистику на форуме и мучился вопросом: "А какие-же всё-таки раздачи самые активные/востребованные?" На форуме только суммарные цифры сегодня, вчера и за всё время; в клиенте по раздачам, но только суммарные - на текущий момент. А хотелось увидеть статистику. Почему-то в первую очередь пришла мысль повесить локальный аннонсер, который добавить в раздачи и на её собирать. Но как-то там всё получалось сложно и мутно. А тут как раз одновременно "на ура" параллельная ветка общения с клиентом через api. Можно напрямую, а можно через готовый модуль Transmission::Client. И подумал, почему бы и нет?

Вот только некоторая путаница сущностях. Но этот вопрос уже немного прояснился: хеш — это про конкретный торрент, имя — конкретная раздача, которую можно идентифицировать по топику. Итого, пишем скрипт: обойти торренты, узнать сколько загружено и затолкать в БД. Тут даже всплывала идея с rrd, но для каждого торрента генерить свой файл как-то не хочется. Скормить кактусу? Было бы интересно, тем более, что он и графики умеет рисовать. Но там тоже на каждый объект свой файл. И с кириллицей тонкости. В общем, не стал заморачиваться, ограничился мускулем. В итоге получилось просто, шустро и эффективно. Сложнее оказалось сообразить чего хочу увидеть и как отобразить. Пока устраивает то, что получилось: вывод агрегируется по именам. Для этого отдельная таблица с информацией имя-хэш- и прочие атрибуты торрента, которые могут быть интересны. В основной таблице только хэш, время и "отдано". Лучше, конечно, было бы хранить сразу разницу, но побоялся что тормозить будет в процессе вставки. лучше я подожду в процессе выборки секунд пять.
Сразу заложил показатели: отдано сегодня, за неделю, за месяц. Потом аппетит появился и добавил "всего" и размер. Затем на имя раздачи повесил линк из поля комментария на топик на форум.

Получилось довольно недурно.

Надо будет ещё автоматическое добавление нового торрента добавлять при скачивании и автообновлении раздачи. А пока ручками и полностью.

Может быть ещё графики были бы интересны.

Хочется ещё пиров увидеть, но, боюсь, этого мне transmission уже не сможет обеспечить.

crower: (Default)
2017-07-25 11:38 am

Закрываю трабл-тикет :)

Давняя загадка, похоже, разрешилась.
Помнится, в процессе бодания с magnetico обнаружил "nf_conntrack: table full, dropping packet". Так вот, после тогдашнего редактирования sysctl больше подобных проблем не наблюдалось. Выходит, недосмотрел, давно не заглядывал в syslog/dmesg. А, началось, кстати, где-то как раз после апгрейда.
crower: (Default)
2017-07-25 08:31 am
Entry tags:

Бодание с systemd

systemd, как некая хрень, данная нам в наказание, чтобы жизнь мёдом не казалась.

Началось всё, конечно, гораздо раньше, но конкретно эта история началась с желания добиться от privoxy адекватной работы. Нет, конечно, он работает правильно. Но основная его задача — вставлять в запросы от transmission к аннонсерам строчки x-forwarded-for. Дабы аннонсеры знали его рабочий адрес, не принимая за таковой адрес выходной ноды. То есть конструкция довольно простая: transmission, iptables, privoxy, tor, аннонсеры. Чуток её усложняет dnscrypt-proxy, предназначенный для противодействия MITM-атакам. Сначала, правда, пытался заюзать tor-resolve, но безопасный ресолвинг сходу получить не вышло, потому и переключился на dnscrypt. Сейчас-то понимаю, что проблема могла быть в том, что tor был тогда не в достаточной степени адаптирован под изменившиеся обстоятельства и, imho, выходная нода попадала под MITM-атаку. Потом всё-равно пришлось делать "тонкую настройку" тору, но на dnscrypt так и остался. IMHO, он всё-таки лучше, чем tor-resolve.
Итого, клиент ресолвит адрес через dnscrypt, шлёт анонсы на трекеры, но их перехватывает iptables и отправляет к privoxy. Тот дописывает x-forwarded-for и заталкивает в тор. В результате анонсеры узнают реальный адрес и отдают его пирам.
Но transmission находится за роутером, который имеет динамический адрес и не знает свой адрес.
Да и никто его не знает. Как-то штудировал протоколы, по которым transmission запрашивает проброс порта и что-о не нашёл штатного способа об этом узнать. Хрень какая-то.
А как-же его узнать?
Варинта вижу два.
1). Идти на роутер и выпарсивать адрес из его страничек. Но это долго и нудно.
2). Можно кого-нибудь спросить. Например на api.apify.org или у wtfismyip.com. Которые дают чистый адрес без необходимости выискивать его на странице. Подсмотрел у друзей по несчастью и клонировал демона, который периодически узнаёт рабочий адрес и подсказывает его privoxy.
И всё было прекрасно, до тех пор пока на пол-дня transmission не потерял связь с трекерами.
С чего бы это?
А с того, что privoxy упал
А почему он упал?
А потому что демон внешнего адреса (назовём его Еидом) был тупой (дарёному демону в зубы не смотрят) и когда вместо адреса получил какую-то хрень, то попортил "зону комфорта" для privoxy, который упал на пол, стал стучать ножками и отказался дальше работать. Еиду-то что — его к жизни всякий раз возвращает кронос, а привокси на такое не был расчитан.
Ну, понятное дело, что скил демона был прокачан, дабы тот впредь сообщал привокси только внятный валидный адрес. Но грусть в душу запала, ибо надеяться на чужие ресурсы, которые могут отвалиться, отсплититься или ещё какая напасть возникнет, негоже. Придётся писать собственного демона, который внешний адрес будет узнавать у роутера.
И казалось бы, всё заработало, но тут-то и выходит весь из себя systemd.
Надо сказать, что я на него давно уже зуб имею. Странный какой-то, запутанный, дурной. Чтобы ковырять, надо кучу терминалов открыть, потому что разные конфиги в куче разных мест, весьма далёких друг от друга. А ещё он сразу невзлюбил miredo. И второй интерфейс на компе тоже. А из-за него якобы networking не поднимается. То есть, по факту он всё-таки поднят. Но поскольку при его поднятии второй интерфейс обругал, что он и так уже запущен, то systemd его пометила как failed.
Так вот, задумался я, что Еид должен быть запущен перед privoxy, дабы прописать правильный адрес до того, как тот начнёт рассылать недостоверную информацию. Но тогда и transmission должен быть запущен только после privoxy. А privoxy должен быть запущен после tor. Ну, и так далее.
Сначала, конечно, накосячил :)
Во-первых, conntrack нельзя, оказывается, настраивать до того, как загружен модуль ;)
И transmission вообще не запустился. Может потому что загнал ему в after networking.target, а networking у меня, как помните, failed.
Зато потом, внимательно поразмыслив кто после кого должен запускаться и удалив некоторые избыточные (и, видимо, запутывающие) зависимости, довёл до нужного вида. В результате чего, даже networking стал подниматься без fail.
Сегодня была как раз вторая (внеплановая) перезагрузка и в этот раз тоже всё поднялось как нужно.
crower: (Default)
2017-07-19 11:48 am
Entry tags:

Печально об убунте

На работе стоит комп с убунтой. Комп не молодой уже, но не задохлик какой-то и среди остального компьютерного парка чуть ли не самый шустрый. Долгое время ресурсов более чем хватало. И вот в прошлом году после очередного апдейта нвидишных дров счастивая жизнь закончилась. Начались глюки, попытки откатиться (но дров нужных уже не нашлось), и в стремлении добиться работоспособости — обновление до последней LTS и переползание на xfce.
Даже года полтора назад если бы мне кто сказал, что машинка моя потребует переползания на xfce, я бы не поверил.
Нафига, если на ней 2 гига памяти и никакого особо прожорливого софта нет? Оказывается, хрен там — хорошо уже было. Ну, про это я уже не раз писал, а сейчас хотел поделиться последним экспериментом.

Есть evolution, который один умеет ходить к ms outlookup server за почтой.
Но сейчас он отказывается подключаться к серверам (любым), потому что якобы у него нет сети.
Сеть есть. Настроена статически и не через рабочий стол. Но evolution её почему-то не признает.
Год назад комп работал немного в другой сетевой конфигурации — в другой сети, на другом интерфейсе. В новую сетевую конфигурацию включал через второй интерфейс, с намерением когда-нибудь подключить первый обратно, но в процессе боданий выяснилось, что много кому не понравилось, что есть eth1, но нет eth0. Пришлось их свопнуть и всё заработало без нареканий. Почти. Вот только evolution этой сети не видит. Как будто это какая-то винда, в которой клиент привязался к конкретной карте, в конкретной конфигурации, через длинный идентификатор. Но в винде-то можно поковырять реестр, а тут-то что?
Ковыряние в логах, пытание с strace показало, что evolution сильно хочет связаться с dbus, но что-то там у него не срастается. Появилась версия, что именно через него он мог бы получить информацию о сетевой конфигурации. А раз не может подключиться, и не может получить конфигурацию (ну, так сделано, блин), значит и сети у него как бы нет.
Может потому что xfce? Вот для проверки и этой версии, решил зайти через Unity и там evolution запустить. Надежды никакой, тем более, в памяти какие-то следы остались что уже пытался подобное провернуть, но почему бы и не попробовать "на свежую голову"? Может мысли какие новые появятся.

Логинюсь через профиль с Unity. Как и ожидалось, памяти уже пожрано compiz под 200 мег, xorg около 120. Кстати, под xfcee памяти xorg потребляет только 79, компиза нет совсем, а а xfdesktop только 46.
Ну, да не за этим мы сюда пришли.
Запускаю evolution — тоже не видит сети. Попытался поконфигурировать сеть - не помогает. Выглядит так, будто бы это всё хозяйство рассчитано на подключение сети с декстопа, а у меня-же статика и прописано по-старому. Пободался, в общем, контролируя по htop съедаемую память. Так как при выедании свободной всё (под юнити) начинает глючить, падать и т.п. Но память ещё есть и можно не беспокоиться. Но надо бы какую-нибудь инфу погуглить. Но FF тоже в последнее время погрузнел и памяти жрёт как та свинья помои. Ну, думаю, запущу вместо него dillo. Запускаю…
…и это было последнее, что смогла запустить убунта… К счастью, - только в этой сессии.
На экране все иконка сразу выпали черезстрочкой, посреди навернулся медный таз нарисовался чёрный треугольник и всё.
С стороны по ssh не пускает - рефузит.
Семь бед — один ресет.

Загрузился. Естественно, в xfce. Решил поделиться - пишу. Чтобы освежить память запустил evolution через терминал. Вижу опять ругается на dbus — сокет не нашёл, зарегистрировать клиент не смог, и ещё какая-то фигня.
Запустился, а тут — батюшки мои! — уже не ругается что сети у него нет!
Уже и за почтой сходил, сволочь, и забрал что надо (и не надо было).
Значить, что-то правильное, всё-таки сделал. :) Ну, во первых, переключал профиль доступа к сети, во вторых, в юнитишной конфигурялке неиспользуемый (старый, бывший основной рабочий) отключи.
Видать мозги вправил.

Пока ещё не очень радуюсь, но заработал — это уже хорошо.
crower: (Default)
2017-07-14 06:20 pm

1G5 seconds unixtime

C полутора-гигениумом юникстайма, дорогие коллеги—программисты. Ну и будущим спейсианам тоже салют.
crower: (Default)
2017-07-04 03:44 pm

Не все mediawiki одинаково функциональны

Жалуюсь.
В рамках проекта [personal profile] vitus_wagner по вычитке книги осознал, что для загрузки материала в mediawiki надо не совсем не то, что предоставляет finereader при "сохранении результата". Форматы есть всякие, но те, что дают разметку - это уже результат вёрстки с распознаванием. А для вычитки может понадобиться оригинал. Оригинал тоже предоставлен, но отдельно. И в исходном виде он имеет размер за три гига. Выгрузка в тексте - это результат распознавания без вёрстки. А для вычитки в медиавики нужен файл с исходными сканами, но подгруженным распознанным слоем, который движёк proofread подгрузит на страничку при первой вичитке страницы.
Значит что надо сделать?
Выгружаем из finereader-а в формате pdf. Это нам нужно для полного кайфа, так как там содержится не просто распознанный текст, но и разметка - где именно он на странице находится. Если честно, это нам нафиг потом не понадобится, но чисто для удовлетворения эстетического чувства, что всё сделано как положено, приятно.:)
С pdf работать не знаю как, но есть инструмент для работы с djvu. Там же есть конвертилка, запустив которую получаем djvu-формат.
Он нам нужен для извлечения текстового слоя в виде S-выражений:

(page 0 0 2600 3544
(line 552 2783 2186 3126
(word 552 2783 2186 3126 "LAMER"))
(line 953 2607 1743 2656
(word 953 2607 1134 2656 "Ouvrage")
(word 1154 2607 1287 2656 "publi\303\251")
(word 1311 2618 1400 2644 "sous")
(word 1422 2618 1460 2656 "la")
(word 1483 2618 1671 2656 "direction")
(word 1695 2618 1743 2656 "de"))
(line 914 2527 1793 2576
(word 914 2538 961 2575 "V.")
(word 988 2527 1286 2576 "Romanovsky,")
(word 1315 2538 1461 2576 "Claude")
(word 1483 2531 1793 2576 "Francis-Boeuf,"))
(line 1138 2447 1534 2495
(word 1138 2447 1305 2495 "Jacques")
(word 1342 2458 1534 2495 "Bourcart"))
(line 1185 673 1492 708
(word 1185 673 1348 707 "PARIS,")
(word 1399 678 1492 708 "1953")))


Следующий шаг — из исходных сканов надо получить те-же djvu.
Но сканы в png и такой конвертилки напрямую не попалось под руку, но есть другие.
К тому же есть сканы в color RGB, а есть в grayscale и один даже оказался почему-то в grya+alpha. Но последнее, думаю, просто недоразумение.
RGB переводим в jpg (например, тулзой convert от ImageMagick) и теперь c44 $src.jpg -slice 100 $dst.djvu
gray переводим (тоже convert) в pgm, а его, например, так: c44 $src.pgm -dpi 300 -percent 4 $dst.djvu
Параметры подглядел из своих старых записей и пока не внимательно не вникал зачем они и где сколько надо, на первое время они и не имеют решающего значния. В данном случае для серых сканов необходимо разрешение, достаточное для вычитки, а цветные так и вовсе не важны.
Проведя означенные операции со всеми сканами получаем постраничную djvu-кацию.
В них подгружаем текстовые слои, выуженные на предыдущем этапе из свёрстанного файнридером документа.
Далее собираем все страницы в мультибандл и "вуаля!" — можно загружать в mediawiki.
Я так и сделал. Файл, индекст, страница. Но в окне редактирования не обнаружил текста.
Расстроился. Что-то сделал не так? Но вроде эксперимент ставил, и подгруженный в документ текст извлекался.
Оказывается. У меня, вообще-то есть два mediawiki-сервера. И эксперимент я ставил на одном, а для вычитки загрузку собирался сделать на другом. И они разные. Там xenial, а там - precise. Но на последнем mediawiki как-то неудачно обновился, а на первом вслед за системой обновление прошло без особых проблем. В итоге на первом 1.29, а на втором - 1.25. Расширения ProofreadPage тоже разных версий. В пользу более старого, то что там специфичные элементы управления не сломались, а на новом их не видно.
Затаив дыхание заружаю файл туда где свежий софт — текстовый слой в наличии.
Значит, собрано всё верно.
А вот на обоих mediawiki кое-что сломалось. :)
crower: (Default)
2017-06-20 11:40 am

Победа над проверкой сертификата

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

У комодо стащил сертификат и бросил в /usr/share/ca-certificates/mozilla.
Вписал его в /etc/ca-certificates.conf.
Запустил update-ca-certificates — все, ок, говорит.
Запускаю wget — так же хрень.
Подсовываю сертификат напрямую — съедает и работает.
Зову на помощь strace — подсказывает, что wget ищет 8d28ae65.0.
Запускаю curl - та-же хрень. strace подсказывает, что curl ищет тот-же файл.
Делаю руками линк, на всякий случай апдейтилку — ок.
Запускаю wget — bingo!

В процессе бодания пытался и reconfigure делать, но в конце уже не трогал.
Вот и думаю — при очередном апдейте/апгрейде не потеряется ли эта хрень.
В записнушке пометку оставлю — в следующий раз полечу по-быстрому.
crower: (Default)
2017-06-20 09:24 am

Борьба за проверку сертификата

Отключение проверки сертификата — плохое решение и было всего лишь временным. Разобраться что там не так ещё предстоит.
Пока обнаружил, что среди установленных комодовских сертификатов есть только такие:

Subject: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO Certification Authority
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Certification Authority
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Subject: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
Subject: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Trusted Certificate Services

А сайт zniis в качестве центра авторизации кивает на:

/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

Что, наверняка, совсем не одно и то-же.
crower: (Default)
2017-06-18 03:25 pm

выгрузка с zniis.ru опять сломалась

Дай, думаю, погляжу чего это робот тихонечко так работает. Давно от него жалоб не было.
А оказыватеся с апреля сайт принудительно отправляет вопрошающего на https. Ладно, wget с этим справился сам и даже не жаловался:
--2017-04-27 05:24:31--  http://www.zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
Proxy-запрос отправлен. Ожидание ответа... 301 Moved Permanently
Адрес: https://zniis.ru/bdpn/operators/router-table/ [переход]
--2017-04-27 05:24:32--  https://zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
Proxy-запрос отправлен. Ожидание ответа... 200 OK
Длина: нет данных [text/html]
Сохранение в: «router-table»

     0K .......... .......... .......... .......... .......... 47,0K
    50K .......... .......... .......... .......... .......... 61,8K
   100K .......... .......... ...                               123K=2,1s

2017-04-27 05:24:35 (59,7 KB/s) - «router-table» сохранён [126072]


Но ровно через месяц случилась какая-то засада с сертификатом:

--2017-05-27 05:24:29--  http://www.zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
Proxy-запрос отправлен. Ожидание ответа... 301 Moved Permanently
Адрес: https://zniis.ru/bdpn/operators/router-table/ [переход]
--2017-05-27 05:24:30--  https://zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
ОШИБКА: невозможно проверить сертификат zniis.ru, выпущенный «/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA»:
  Невозможно локально проверить подлинность запрашивающего.
Для небезопасного подключения к zniis.ru используйте параметр «--no-check-certificate».


Увы, выгружающий скрипт писал "по быстрому", "на коленке", и обработку таких ошибок не закладывал. Поэтому с 27 мая все файлики-таблицы нулевого размера. В принципе, эта хрень никому явно и не нужна, а выгружается на всякий случай. Но вот вдруг такой случай возникнет, а у меня свежачка нет?
Добавляю --no-check-certificate, запускаю, но тут уже и "парсер" начинает кашлять и плеваться. Ну, думаю, ещё и внутри чего-то изменили. Начинаю разглядывать выгруженную страницу, а там хвоста нет. Заканчивается страница открытым div-ом, как будто что-то на сайте молчаливо сломалось.
Хм, думаю, и скармливаю урл validator.w3.org, но тот сразу нос воротит: 500 Can't connect to zniis.ru:443 (certificate verify failed)
Выходит, думаю, это не у меня какие-то косяки в технологии, а всё-таки на сайте.
Посмотрел хронологию: такая хрень появляется с 27 апреля - в самый раз как стали заворачивать на https.
«А ещё сайт ЦНИИС, называется!» ;)

PS. Парсинг придётся адаптировать.

UPD. Выяснил, почему с парсингом возникла проблема. С какого-то момента "там" решили, что слишком дофига таблиц в одном месте держать — не по феншую. Стали раскладывать по подпапкам. Названия подпапок с пробелами. Подпапки, да ещё и с пробелами в именах не были продусмотрены. :) "Адаптация" обошлась дешево — пришлось выпарсивать имена источника целиком и отдельно генерить локальное имя. Первое нужно для подкрузки недостающего, второе - для локального хранения. Так-то я их потом перекладываю в архив по подпапкам Архив/YYYY, а из-за того что у zniis старьё не удаляется, можно было либо скипать старое, либо проверять наличие и в архиве. Скрипт сделал лояльным и гибким — его устроит наличие файла где бы он не лежал.
Но по уму, конечно, надо переделывать залипуху на bash+grep+se+wget на нормальный скрипт. Например, на perl. Тем более, с libcurl руку немного набил, а остальные вещи делаются горазно гибче и проще.
crower: (Default)
2017-06-14 10:42 am

perl & libcurl

UPD. Решил почистить лишнюю лирику и оставить самый навар.

WWW::Curl документирован слабовато и большей частью отсылает на сайт курловой документации.

Чтобы заюзать NTLM-авторизацюи надо сделать:

$curl->setopt(CURLOPT_HTTPAUTH, CURLAUTH_NTLM);


Для простого POST с передачей параметров в теле запроса не надо пользоваться WWW::Curl::Form, как можно было бы подумать, глядя в доку. Нужно:

$curl->setopt(CURLOPT_POSTFIELDS, $data);
$curl->setopt(CURLOPT_POSTFIELDSIZE, length($data));
$curl->setopt(CURLOPT_POST, 1);

Если использовать WWW::Curl::Form, то курл будет заворачивать каждый параметр в отдельный Content-Disposition. Соответственно, это и накладные расходы, и не факт что CGI умеет их отттуда извлекать.
Хотя, зачем вручную считать размер мне не понятно. Почему это не мог бы сделать сам курл?
crower: (Default)
2017-06-10 08:08 pm

Автоапдейт торрентов

Ура. Сегодня автоапдейтилка торрентов отработала в первый раз в полностью автоматическом режиме.
В прошлый раз она обнаружила обновлённый торрент, но не смогла его обновить по причине того, что старый линк на топик на форуме был прописан с протоколом http, а научена была обнаруживать https. Получилось по-дурацки смешно: "ой, торрент обновился! ой, нет, его апдейтить не умею".
А старых торрентов, которые ещё с реез создавались, дофига. Допилил: пофиг протокол, всегда использовать https на рутрекере. Потом её тестил — справилась. Но условия-то уже изменились. И хоть попытался максимально повторить исходную ситуацию (удалил новый торрент, запустил старый), но на форуме-то топик расспасибить уже не могу ;)
Хотя там, кстати, возникла и другая закавыка: содержимое быто изменено, что только запутало, потому что подумал что какие-то грабли всё-таки у меня.
Ну а в этот раз руки вообще не прикладывал.
Жаль только апдейт обнаруживается далеко не сразу. В прошлый раз реагирование произошло минут через десять, в этот — 33 минуты. Из-за того что трекер просит делать анонсы раз в час, до часу это запаздывание может доходить.
Поэтому с регулярно обновляемыми торрентами наваял супервизора, который раз в пять минут проверяет смену топика на форуме. Таких раздач у меня было штук шесть, а сейчас осталась только одна. Все серийные - фильмы и одна телепередача. Удобно мониторить не особо заморачиваясь, по титлу. Но если понадобится отслеживать что-то другого типа, придётся делать универсальную штуку: есть поле "зарегистрирован", старое запомнить и ждать когда обновится.
crower: (Default)
2017-06-09 08:19 am
Entry tags:

magnetico v0.5.0

Вышел magnetico версии v0.5.0.
Наконец-то перестал регулярно падать с "Bad file descriptor".
Проблема, как и подозревал, была в попытке использования "протухших" соединения.
После этого кустарный мониторинг стал показывать, что количество открытых сокетов может увеличиваться и выше 500, чего раньше никогда не видел. Видел даже за тысячу. И не падал!
Зато стало попадаться предупреждение о какой-то недопустимой операции.
Не знаю, что меня сподвигло заглянуть в dmesg.
Увидел большое количество "nf_conntrack: table full, dropping packet" и траблшатинг пошёл по накатаной колее :)
Увеличил net.netfilter.nf_conntrack_max и net.nf_conntrack_max — сообщения в dmesg прекратили появляться и магнетико перестал жаловаться на недопустимую операцию.
Заодно обнаружил, что у краулера появились новые опции.
Включил дебаговую отладку и она мне понравилась.
Надо, наверно, сливать её в лог-файл, чтобы от не какой-нибудь прок был.
Не забыть бы только, :) а то с интенсивностью харвинга несколько десятков тысяч торрентов в сутки, размер лога может быстро выйти из под контроля. ;)
Ах, нет! ~ Xe4 торрентов в сутки это он собирал в предыдущие 6 дней (от 5 до 10), а вчера получилось около 130.
Параллельная мысль: вот только статистика слишком долго считается. Не сделать ли снапшот, как я для DPL недавно делал :)
И это при том, что сапгрейдил его вчера только часов около восьми вечера. Впрочем, может считалка статистики использует не локальное, а универсальное время, и тогда стахановский рывок получился не за 4 часа, а за 12. Ну, за сегодня и посмотрим, на сколько эффективнее стал процесс.
Плюс с базой стал шустро работать. Раньше после падения запускался долго, очень долго, несколько минут. Как-будто sqlite пытался почекать и/или восстановить базу после внезапно потерянного коннекта. А тут пришиб (чтобы лог прикрутить), запустил — и через 23 секунды появилось первое INFO Added. А судя по первому дебагу работу он начал уже через полторы секунды.
Удивило "Maximum number of neighbours now 1872" через 6 секунд. Неужто так быстро нахарвил? Потом количество уменшилось и теперь держится около 6½ сотен. fetch metadata task count сначала плавно добрался до четырёх с половиной сотен, а потом уменьшился. Иногда спускается ниже 300, но в основном держится около 3½ сотен.
И стал постоянно ругаться на "SybilNode operational error: `[Errno 22] Invalid argument`".
Пока ещё не выяснял что это за хрень.
Похоже, fetch metadata task соответствует количеству открытых сокотов. Можно от кустарного мониторинга отказываться. ;) Вот только tail -f log | grep word на логе в потоке работать не будет. Надо будет что-то сочинять.


UPD. Снапшот не понадобился. Заглянул в базу — там индекс только на хеш был. А статистика с распределением по дням строится с не индексированном полем. При полутора миллионах записей понятно что тормозить должно. Создал индекс — график стал отображатся через считанные секунды. Накладные расходы мизерные а удобство существенное. :)
crower: (Default)
2017-06-05 01:21 pm

Поиск источника проблемы продолжается…

Не смог решить загадку, как условия оной усложнились.

Вот уже который день необходимости в перезагрузке роутера не наблюдается. Пинги ходят надёжно, как в швейцарском банке. :)
Ладно если бы нагрузка упала. Так ведь наоборот, нагрузил железку. Опять запустил magnetico, и тот трудится непрерывно. В прошлый раз, кстати, он наоборот ускорял ухудшение связи, а тут — третьи сутки, как 20/20 пингов возвращаются.
Роутер? Но какой фактор мог повлиять? Разве что похолодало на улице в эти дни. Хотя дома на градуснике что рядом с компом как было 22-24. Хорошо, в следующий раз, если случится такая проблема, попробую поохлаждать. :)
Провайдер? Возможно. Помнится в прошлый раз, когда были проблемы, связанные с хреновой картой, симптомы были похожие. И техник говорил, что мой комп не закончив предыдущую сессию, начинал новую. А провайдерское оборудование, как я понимаю, трафик мне отправляло по обоим сессиям. Фича, что-ли, для лоадшаринга. Но одно дело если бы шнурка было два и это был реальный лоадшаринг, и совсем другое, если отправляемое по первой сессии/шнурку трафик уходит в никуда…
crower: (Default)
2017-05-26 08:10 pm
Entry tags:

Загадка от провайдера

В последнее время с интернетом стала наблюдаться пакость. Поработает некоторое время и начинает подтормаживать.
С пол-года уже, наверно. Пускаю куда-нибудь пинг — пинги теряются.
Перегружаю tplink — всё опять работает как часы. В последнее время просто каждый день перегружаю точку доступа. За сутки тормоза практически не заметны, но на всякий случай, чтобы не запускать симптомы...
То ли провайдер мутит, то ли точка глючит. IP-адрес белый, но динамический и поэтому не знаю может ли какой-нибудь левый трафик душить пропускную способность. Хочется думать на провайдера, но в точке тоже не уверен. По крайней мере временами, когда наблюдаются сильные тормоза, даже до точки добраться бывает проблематично. Через локалку. То есть доступ к его интерфейсу совершенно не должен зависеть от wan. Если только через нагрузку. В самом начале инет включался прямо в мой комп и тогда можно было ещё чего-нибудь наснифить прямо на компе. А сейчас лениво что-то переделывать чисто для эксперимента. Эх, стар я стал. :)


А сегодня обнаружил ещё одно чудо. Перед перезагрузкой по привычке пускаю пинг, и по нему вижу когда точка перезагружается. И тут вдруг обращаю внимание, то до перезагрузки пинг был 68мс, а после — 74мс. Стабильно.
Раньше такого что-то не замечал.
crower: (Default)
2017-05-25 08:27 am

хронология команд

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

Есть на станции такие файлы, в которые она сохраняет команды между дампами. Зовут их RELCMDHDF, если что.
Новые создаются при каждом дампе, старые становятся не нужными и если специально не пошевелиться, плодятся годами. Место поедают, конечно, но файлы, в общем-то, не большие. Впрочем, технология выделения дискового пространства там чуточку другая, из-за чего места занимать они могут гораздо больше, чем реально используют. Если станция не сильно старая, то проблема нехватки места может так и не наступить. Скорее станцию заменят. :D
Но вот в рамках эксплуатации могут возникать сложности. Работает там конструкция типа кластера и в случае смены активного узла происходит синхронизация дисков. Сначала будет попытка сделать быстрый апдейт - только того, что изменилось после того как узел находился в забытьи. Если не получилось и процесс затягивается, то происходит переключение на длинный апдейт, то есть тупая синхронизация всего подряд, чуть ли не по кластерам. И чем больше всяких файлов валяется, тем вероятнее переключение на длинный процесс. Поэтому много лет назад, приехавший настройщик, тяжело вздохнут собрался поудалять древние файлы. Хорошо что он ленился. Я тогда про них ещё ничего не знал, а как узнал какое богатство собираются удалять, спохватился и уговорил что сам всё сделаю. Товарищ, конечно, обрадовался, потому что автоматизировать рутинные операции не умел, а команд вводить пришлось бы долго. А тут ему предлагают ничего не делать, но работа при этом сделается. В итоге, файлы эти я скачал, и только после этого удалил те что надо. Потом уже сделал нужные настройки, чтобы станция сама эти файлы и через даталинк отправляла, и удаляла старые. В результате получил архив вносившихся в станционные данные изменений. Зачем? Очень удобно отыскивать когда нечто делалось. Например, возникает вопрос: имеется странный маршрут, зачем и почему он сделан таким? Идеальным был бы электронный журнал, хоть и требовал бы дополнительных телодвижений на протоколирование всего подряд. Но начиналась эта работа слишком давно. Есть два шкафа толстых папок распоряжений, по которым эти изменения вносились. Но когда? И вот тут на помощь приходит RELCMDHDF.
Долгое время пользовался простым grep-ом. Потом прикрутил врапер для удобства. Со временем к враперу прикрутил отыскивание по TRLOG1FILE, в который вообще все диалоги со станцией пишу. Собирался было прикрутить скрипт на веб-страницу, но задумался … и решил, что нужно грузить всё это в БД. Глаза боятся, а руки делают.
В результате получил возможность быстрого поиска, удобного доступа (и не только мне), и сводной таблицы.
Сотрудники тоже оценили фичу. Теперь даже непонятно как можно было без этого обходиться. :)

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

В общем, сделал один раз, а удовольствие приносит многократно.
crower: (Default)
2017-05-23 08:27 am

Неэффективная оптимизация

С оптимизацией получился облом.

Напомню, что была попытка соптимизировать запрос с select ... where date(field) in (...) group by .... Я в курсе, что конструкция field in (...) сама по себе дорогая, но вполне приемлема, если потеря скорости незначительна, а альтернатива может оказаться ещё дороже.

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

Попробовал другое "дешёвое" решение — внедрить ограничение диапазона, где код where date(field)≥{min_time} and date(field)<{max_time} призван был сократить первоначальную выборку, и уже после этого работал бы var in (...). Нужно было планчик составить, но лениво. А потом оказалось что и var in лишний. С выборкой нужных дат в самом скрипте всё оказалась гораздо быстрее. И поначалу всё заработало как надо. И дело даже не в кешировании. Потому как регулярно, раз в час поступают новые данные.

Эффект был кажущимся из-за того, что на момент тестирования дат было не так много и group by на все эти даты не сильно тормозил. Но наступление события "С", ради которого весь этот сыр-бор, задержалось. И получилось что между первой и последней датой времени прошло настолько много, что быстродействие от экономии на отказе от var in полностью пожралось group by. Долгим и бессмысленным.

Ещё бы:

  • 4 таблицы: 1.2млн, 1.3млн, 26млн и 27млн записей.
  • интересующие данные (без уточнения по дате) составляют 64К, 10К, 130К и 20К записей.
  • в таблицах сидит timestamp, а выборку и результат нужно делать от функции по нему. Хоть через substr, хоть по date.

Можно было плюнуть и вернуться к старой схеме, но "мы не привыкли отступать"© и это оскорбляет эстетическое чувство.

Поэтому пришлось делать красиво и по-полной схеме. При обращении к странице, скрипт запрашивает данные, уже сгруппированные по дате и лежащие в специальной дочерней таблице. Если на определённую дату данных нет, то запрашиваются данные в родительской таблице. Если они оказываются полными за указанную дату (24 часа, 1440 минут или 86400 минут), то они вставляются в дочернюю таблицу и в следующий раз будут извлекаться оттуда. Считать их заново будет не нужно. Операция сия была необходима для одного определённого объекта, так что пухнуть дочерние таблицы не будут. При периодическом опросе данные за прошедшие дни обстчитываются постепенно, и только за текущий - постойнно. В результате подтормаживание составляет при пересчёте прошедших суток считанные доли секунды, а за текущую дату - даже не заметно. Всё-таки выборка по timestamp ≥ {time} and (timestamp < {time} + INTERVAL 1 DAY) гораздо быстрее, чем упоминавшиеся ранее конструкции. Да и group by нужно будет убрать, т.к. алгоритм и ткак каждый раз выдёргивает по одной строке.

Зато теперь всё классно. :)

crower: (Default)
2017-05-16 10:30 am
Entry tags:

фейсбучек чтобы не заныкал, хочу вот это сохранить :)

Спасибо Виктории.


обидеть Таню может каждый,
не каждый может убежать
----
ищу приличную работу,
но чтоб не связана с трудом
----
Read more... )
crower: (Default)
2017-04-09 01:57 pm

Наблюдая…

…весь тот катаклизьм в ЖЖ, принял решение сворачивать там манатки:
1. Перестать кросспостить посты отсюда туда.
2. Поудалять тамошние посты, благо всё уже импортировано в дрим.
3. Свести тамошнюю активность до минимума.
Будет хуже там — больше народа станет перебираться в т.ч. сюда.