crower: (Default)
Да-да, у меня тоже. Сразу после апгрейда с 12.04 до 16.04. Да-да, с тем самым "любимым" systemd, через который абсолютно нихрена не видно. Впрочем, надо рассказать всё последовательно и понятно. :)

Есть комп с двумя сетевушками, одна из которых смотрит в интернет. После перезагрузки компа networking.service "недогружается", как говорит systemctl "loaded failed failed". journal -u networking красноречиво сообщает (специально сделал свеженький рестарт):
фев 23 20:55:23 my.home systemd[1]: Starting Raise network interfaces...
фев 23 20:55:26 my.home ifup[998]: RTNETLINK answers: File exists
фев 23 20:55:26 my.home ifup[998]: /sbin/ifup: waiting for lock on /run/network/ifstate.eth1
фев 23 20:55:27 my.home ifup[998]: Failed to bring up eth0.
фев 23 20:55:27 my.home systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
фев 23 20:55:27 my.home systemd[1]: Failed to start Raise network interfaces.
фев 23 20:55:27 my.home systemd[1]: networking.service: Unit entered failed state.
фев 23 20:55:27 my.home systemd[1]: networking.service: Failed with result 'exit-code'.


Но если посмотреть ifconfig, то как минимум lo, eth0 и eth1 подняты. И всё бы ничего, и всё бы работало если бы не желание выстроить цепочку загрузки по-правильному, через systemd. Раньше, кстати, я даже не обращал внимание на этот статут долгое время, но когда возникают какие-то проблемы, этот статус привлекает внимание: "а вдруг это тут что-то сломалось, а из-за ложно-положительного статуса failed я этого не могу увидеть". Ну и начал прописывать зависимости. И то transmission перестаёт подниматься, то tor, то privoxy, то тулза, заниающаяся отслеживанием для privoxy внешнего адреса (да, в инет ходим через роутер-файервол, а внутри серые адреса).
В принципе, порядок какой-то тоже должен быть. Нафиг нам privoxy, который прокладывает маршрут через tor, если tor0а ещё нет? transmission до рутрекера тоже не дотянется без privoxy, а значит и без tor-а. Адреса аннонсеров того-же трекера вписаны прямо hosts, но если что, то корректный ресолвинг можно получить через dnscrypt-proxy.
Короче говоря, пока не всё поднимается как нужно, придумал полу-ручные костыли.
Например, после перезагрузки всё загрузилось кроме privoxy. Есть пара скриптов, первый из которых показывает как поднялись сервисы из группы риска, а второй - лечит больной networking и доподнимает так и не поднявшееся.
И теперь основной вопрос - как лечить networking. "systemctl start networking" не помогает.
Обычно проблемы настигают со стороны eth0, но несколько раз "недоподняный" оказывался и eth1. До глубинной проблемы добраться пока не получилось, но "симптом" обнаружил. В /run/network генерятся файлы ifstate, ifstate.lo, ifstate.eth0 и ifstate.eth1. Если всё ок, то в ifstate прописаны все родные интерфейсы (lo=lo и т.д.), а в ifstate.lo просто "lo" и т.д. Но если интерфейс "недоподнят", то в файле ifstate.eth0 пусто, и в ifstate его строчки тоже нет. Но, по ifconfig, напомню, он уже есть и работает. Т.е. файлики-то тупо информационно-сервисные. Поэтому... вписываем в файлики недостающее, и после этого "systemctl start networking" показывает что networking таки поднялся.
фев 23 20:58:22 my.home systemd[1]: Starting Raise network interfaces...
фев 23 20:58:23 my.home systemd[1]: Started Raise network interfaces.


Ну а раз лечащий скрипт стал создавать, то и вставил проверку - кто ещё не поднялся и соответственно всех разом "systemctl start $services" прошу поднять.

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

PS. И, конечно, до systemd всё прекрасно работало.
crower: (Default)
Жили на двух одинаковых убунтах два одинаковых пиджина: один дома, другой на работе.
На одном из телеграм-канала картинки показывались, на другом — нет.
Настраивал, понятное дело, не по единой инструкции, а по отдельности. Сначала тупо прошерстил все параметры в надежде найти какую-нибудь опцию. Ничего на нашёл. Несколько раз. Да, про конфиги тоже думал. Никаких подходящих названий, наводящих на мысль о сокрытии или отображении картинок тоже не нашёл.
Но, блин, пойди сравни когда секции в конфигах хоть mcdiff-ом, если они в разном порядке. Писать парсер xml-формата, который посортировал бы их тоже лениво.
Короче. Скриншотнул список активных модулей на одном и давай сравнивать на другом. На втором (который не показывал) было включено модулей раза в полтора-два больше. Ну, думаю, для начала хотя бы синхронизирую. Поотключал "лишее", что должно в том числе улучшать ленту чата, и bingo — картинки стали отображаться. А ведь нигде там даже не пахло вырезанием картинок...
crower: (Default)
Жижовая болезнь у DW?

Отвечаю на комент, кликаю и получаю "Ошибка при установлении защищённого соединения, бла-бла-бла".
Пробовал несколько раз — "тот же хрен, только в другой руке"©
Кликаю F12, чтобы хоть увидеть на каком этапе получается облом, а хрен там — комментарий благополучно уходит и открывается нитка обсуждения уже с ним.
Что это было? Может квантовые эффекты Fx Quantum ;) а может временное нарушение постинга на DW. Теоретически ведь возможно, что чтение DW работает, а временно постинг не работал.

FF 57

Nov. 17th, 2017 01:43 pm
crower: (Default)
Отвалились расширения (из наиболее желаемых) "Context Search X", "NoScript", "Tab Memory Usage".
FoxyProxy обновился, но настройки слетели. Оказалось, что синтаксис шаблонов изменился. Типа по требованию мозилы пути не могут входить в шаблоны. Новый интерфейс настройки не понравился. Хорошо, что нашёлся импорт и снятый когда-то дамп настроек со старого. Импорт не справился с конвертацией настроек в новый формат, так что пришлось вручную почти всё адаптировать. С другой стороны, может оно и к лучшему, потому что в новых паттернах раздражавших (и опасных) убожеств типа "http*://host/*" уже не будет — отдельная опция для протоколов и без масок: http/https/оба.

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

Когда-то для отвалившихся расширений тупо менял максимальную версию в rdf, но сейчас такой манёвр так просто не пройдёт. В крайнем случае кое-какие можно был поправить отдельным паком (типа локальным), но теперь такой номер, скорее всего, не пройдёт: "Mozilla проверяет и "подписывает" дополнения, которые следуют набору требований к безопасности". Хотя, конечно: "Developer Edition и Nightly-версии Firefox позволят вам обойти требование подписи дополнений, если вы измените параметр xpinstall.signatures.required на false в редакторе конфигурации Firefox (страница about:config)".

Ну, NoScript, надеюсь пока прикроет Ghostery. А вот "Context Search X" чем заменить? Надеюсь его таки-допилят.
crower: (Default)
Попалась музыка в DTS. Файлы раз в десять толще чем обычные mp3, но подвоха не заподозрил.
Записал на планшет (с андроидом), а он мне белый шум играет. Расширение wav mp3-плеер играть умеет, но и там фигня. Конвертнул sox-ом, но и там белый шум. Хрень какая-то. Выгуглил совет пользоваться vlc. Играет что надо. При этом говорил что 6 каналов, а soxi говорит что всего два. Пытался sox-ом конвертить с принудительным указанием количества каналов — "та же хрень, только в другой руке". Попросил vlc сохранить/конвертнуть - бинго. Получил нормальный mp3. Но оригинальные файлы сейчас далеко и канал тонкий - вытаскивать оригиналы слишком долго. Полез в справку vlc чтобы через командную строку конвертнуть, но заблудился. Но vlc вроде юзает ffmpeg?
Попросил его конвертнуть файлики в mp3 - bingo!
А я-то думал, что нет ничего круче "швейцарского ножа". :)
crower: (Default)
Прибежала пачка обновлений. Большая часть иксовая плюс что-то кейбордовое. После апгрейда система отломала переключалку на русский, а через панельный индикатор переключались только два языка туда-сюда. Выход/вход из профиля не помог. Пришлось ребутнуться.
Зато ещё раз проверил как поднимается система. В обычной ситуации делать это лениво, тем более поттеринговый паразит выгружает комп на минуту-две дольше, чем было до него. В итоге всех ранее проблемных демонов разрулил: ntpd пдоднимается без нареканий, в нужном порядке tor, privoxy, dnscrypt-proxy, transmission-damon, extip. Осталась одна беда — networking, который поднимает оба интерфейса, но с одним из них происходит какая-то странность: "RTNETLINK answers: File exists". В результате в /run/network/ один из файлов ethx пустой и в ifstate его тоже нет.
Пока, чтобы привести всё в норму, тупо вписываю недостающее и прошу start networking. Система говорит "а, ну теперь всё в порядке" и всё едет дальше. Забекапил лог леннартовского поделия, взглянул на это дело и вижу что journalctl -xu networking недодавал мне одну строчку: "Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf". Ну, это другое дело! Теперь-то понятно что ему может не нравится. Вообще-то я сам в своё время отрывал линк, потому что эта козлина переписывала мне мои настройки совсем не так как надо.
В, общем, теперь понятно где и что надо лечить.
crower: (Default)
В продолжении разговора.

Ваять systemd-style конфиги для ntpd пока не охота. Полез в /etc/rc3.d и офигел.
Раньше какие только порядковые номера там не видел, а теперь всё как-то скомкано. Да, ntp был в первой партии, но там был и bind, а bind-у больше ничего не было нужно кроме работающего интерфейса.
А сейчас бинду нужен, как минимум, dnscrypt-proxy. Или, на худой конец, tor-resolver. #нуивот.
Но раньше и тор, и transmission-daemon были двадцатыми, а сейчас какая-то скотина сделал тор четвёртым, а трансмишин вообще первым. И это не смотря на то, что в настройках трансмишина чётко написано запускать после тора, бинда и привокси.
В общем, для начала отодвинул ntp по порядку подальше.
С остальным ещё предстоит разбираться.
crower: (Default)
Рано радовался.
Как там система умудрилась пару раз подняться без даунгредового статуса не знаю, но после этого два раза подряд загружается с проблемами. Как всегда, с 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)

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

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

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

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

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

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

crower: (Default)
Давняя загадка, похоже, разрешилась.
Помнится, в процессе бодания с magnetico обнаружил "nf_conntrack: table full, dropping packet". Так вот, после тогдашнего редактирования sysctl больше подобных проблем не наблюдалось. Выходит, недосмотрел, давно не заглядывал в syslog/dmesg. А, началось, кстати, где-то как раз после апгрейда.
crower: (Default)
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)
На работе стоит комп с убунтой. Комп не молодой уже, но не задохлик какой-то и среди остального компьютерного парка чуть ли не самый шустрый. Долгое время ресурсов более чем хватало. И вот в прошлом году после очередного апдейта нвидишных дров счастивая жизнь закончилась. Начались глюки, попытки откатиться (но дров нужных уже не нашлось), и в стремлении добиться работоспособости — обновление до последней 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)
C полутора-гигениумом юникстайма, дорогие коллеги—программисты. Ну и будущим спейсианам тоже салют.
crower: (Default)
Жалуюсь.
В рамках проекта [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)
Борьба увенчалась победой. Не сразу, и с какими-то дурацкими брыканиями.

У комодо стащил сертификат и бросил в /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)
Отключение проверки сертификата — плохое решение и было всего лишь временным. Разобраться что там не так ещё предстоит.
Пока обнаружил, что среди установленных комодовских сертификатов есть только такие:

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)
Дай, думаю, погляжу чего это робот тихонечко так работает. Давно от него жалоб не было.
А оказыватеся с апреля сайт принудительно отправляет вопрошающего на 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)
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)
Ура. Сегодня автоапдейтилка торрентов отработала в первый раз в полностью автоматическом режиме.
В прошлый раз она обнаружила обновлённый торрент, но не смогла его обновить по причине того, что старый линк на топик на форуме был прописан с протоколом http, а научена была обнаруживать https. Получилось по-дурацки смешно: "ой, торрент обновился! ой, нет, его апдейтить не умею".
А старых торрентов, которые ещё с реез создавались, дофига. Допилил: пофиг протокол, всегда использовать https на рутрекере. Потом её тестил — справилась. Но условия-то уже изменились. И хоть попытался максимально повторить исходную ситуацию (удалил новый торрент, запустил старый), но на форуме-то топик расспасибить уже не могу ;)
Хотя там, кстати, возникла и другая закавыка: содержимое быто изменено, что только запутало, потому что подумал что какие-то грабли всё-таки у меня.
Ну а в этот раз руки вообще не прикладывал.
Жаль только апдейт обнаруживается далеко не сразу. В прошлый раз реагирование произошло минут через десять, в этот — 33 минуты. Из-за того что трекер просит делать анонсы раз в час, до часу это запаздывание может доходить.
Поэтому с регулярно обновляемыми торрентами наваял супервизора, который раз в пять минут проверяет смену топика на форуме. Таких раздач у меня было штук шесть, а сейчас осталась только одна. Все серийные - фильмы и одна телепередача. Удобно мониторить не особо заморачиваясь, по титлу. Но если понадобится отслеживать что-то другого типа, придётся делать универсальную штуку: есть поле "зарегистрирован", старое запомнить и ждать когда обновится.
crower: (Default)
Вышел 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. Снапшот не понадобился. Заглянул в базу — там индекс только на хеш был. А статистика с распределением по дням строится с не индексированном полем. При полутора миллионах записей понятно что тормозить должно. Создал индекс — график стал отображатся через считанные секунды. Накладные расходы мизерные а удобство существенное. :)

Profile

crower: (Default)
crower

February 2018

S M T W T F S
    123
45678910
11121314151617
181920212223 24
25262728   

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 25th, 2026 09:06 pm
Powered by Dreamwidth Studios