Brownian motion

around the essentials…

 

Публікації Tagged ‘Linux’

LilyPond → WordPress: поновлювати опубліковані партитури просто!

Задача: маємо багато партитур, опублікованих на сайті під WordPress, інтенсивно з ними працюємо, — тож варто мати механізм поновлення партитур після редагування. Ноти набираємо у LilyPond.

Дуже коротко:

  1. На сайті публікуємо партитури із додаванням суфікса відповідно до дати та часу збереження (генерування) партитури, напр. назва файлу ОйЧийТоКіньСтоїть_20170406_175520.pdf означає, що партитуру було згенеровано з файлу ОйЧийТоКіньСтоїть.ly 6 квітня 2017 року о 17:55:20. Звісно, такі суфікси додаються автоматично при генеруванні. Таким чином, до речі, уникаємо можливих нюансів із кешуванням опублікованого.
  2. LilyPond використовує простий текстовий формат, тому використовуємо систему зберігання та відстеження версій Mercurial.
  3. На власному комп’ютері редагуємо партитуру, після чого: hg commit && hg push.
  4. На сервері маємо те саме сховище mercurial; після редагування виконуємо hg pull && hg update.
  5. На подію update на сервері сконфігуровано hook, який запускає скрипт.
  6. Скрипт видає перелік файлів .ly, які, імовірно, треба поновити на сайті WordPress. При цьому ми могли редагувати, наприклад, ОйЧийТоКіньСтоїть_alto.lyi (а не сам ОйЧийТоКіньСтоїть.ly) — скрипт показує саме «головний» файл.
  7. Наступні кроки може виконувати цей саме скрипт, проте це не задача сховища ,) Віддамо це іншому скрипту.
  8. Інший скрипт бере файл по файлу усі партитури, які, імовірно, треба поновити. Для кожної партитури:
    1. Знаходимо у каталозі wp-uploads нашого сайту раніше завантажені файли: ОйЧийТоКіньСтоїть_([0-9]{8}_[0-9]{6}).pdf.
    2. Якщо щось знайшли — виконуємо lilypond -o ОйЧийТоКіньСтоїть_`date +"%Y%m%d_%H%M%S"` ОйЧийТоКіньСтоїть.ly.
    3. Якщо успішно — кличемо wp cli! Він замінить (операція search-replace) у табличках WordPress усі згадки ОйЧийТоКіньСтоїть_<стара_дата> на ОйЧийТоКіньСтоїть_<нова_дата>.
    4. Видаляємо у wp-uploads старі файли, переносимо туди нові.

І все)

Насправді це все трохи складніше, бо ми використовуємо мітки для генерування різних варіантів із одного джерела (при цьому файли з мітками можуть називатися ОйЧийТоКіньСтоїть--Torig_20170407_101222.pdf). Крім того, до якихось файлів WordPress уже міг додати «порядковий номер», тоді назва буде, наприклад, така: ОйЧийТоКіньСтоїть--Torig_20170407_101222-1.pdf.

Але це все легко вирішується.

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

(1 votes, average: 5 out of 5)

Трохи роботи .)

Щойно дописав підтримку IPv6 для свого конфігуратора (Django/Python) шейпера (HTB/Linux).

«Воно жахливе, але працює чудово»™ .)

(No Ratings Yet)

Любителям руської мови — книжка :-)

Вже надрукували, ще не отримали надруковане, але вже опублікували «повноякісний» PDF (лише обрізаний по формату, та ще з підсвіченими гіперпосиланнями — у надрукованому немає ані підсвітки, ні гіперпосилань.)).

«Це було славне полювання» © Акела

Усім любителям дякую :-)

(No Ratings Yet)

bc як конвертор основи

Утиліту bc (an arbitrary precision calculator language) можна досить зручно використовувати для конвертування чисел між основами, в тому числі у скриптах:

$ echo "ibase=16; obase=2; 5F" | bc
1011111
 
$ echo "ibase=16; obase=8; 32" | bc 
62
 
$ echo "ibase=10; obase=4; 12" | bc 
30

Може, комусь і згодиться.

(No Ratings Yet)

tc filter … protocol 802.1q … u32 та фільтрування VLAN трафіку

Викладене нижче перевірялося для 2.6.26 та 2.6.32. Обережно, у 2.6.31, ніби, є нюанси.

Зауважу, що я не дивився у cls_u32.c тощо — і можу капітально помилятися .)

Отже, спершу трохи про «логіку фільтрування»:

  • Коли ми пишемо tc filter ... protocol <proto> u32 match u<length> <value> <mask> at <offset> — ми маємо на увазі зміщення «від позиції НУЛЬ», ядро має на увазі «від початку IP пакета».
  • Якщо у Ethernet пакеті немає IP — можна фільтрувати лише всі пакети для вибраного протоколу (як, наприклад, тут фільтрують всі STP пакети), а не по масці/зміщенню. «Нуля» в такому пакеті, схоже, немає.
  • У «дереві» фільтрів мають бути лише фільтри для одного і того самого протоколу. Якщо хочеться для різних, то можна щось придумати, але про це іншим разом.

Тепер — «демонстративний» (але цілком робочий) скрипт, яким можна фільтрувати влани 22 і 310 у різні класи (мова, як завжди, про linux bridge із сконфігурованим шейпером; при цьому крізь цей комутатор бігають 802.1q tagged пакети):

» Скрипт і коментарі… »

(No Ratings Yet)

“Покращення” сфотографованого тексту

На цей раз маємо задачу: не надто вдало сфотографовані сторінки тексту треба «пристосувати» для друку — підняти контраст, різкість, зробити «виразнішими».

Як завжди, результат можна отримати легким (easy-to-use) та важким (where-am-i?..) шляхом — розглянемо обидва.

(Звичайно ж, це не єдиний алгоритм, яким можна досягти бажаного результату.)

Зміст

  1. «Легкий» — графічний — шлях
  2. «Важкий» — з командного рядка
  3. Висновок

» Читати далі — алгоритми, знімки екрану, пояснення… »

(No Ratings Yet)

Конфігуратор HTB шейпера

*subj* :-)

Давно було зрозуміло, що без нормального конфігуратора керувати нормальним шейпером «важкувато», але… все ускладнювала одна обставина — я не програміст (тм).

Чим мене не влаштовують наявні інструменти?

По-перше, всі знайдені вирішують трохи інші задачі, простіші; зокрема, я так і не знайшов конфігуратора для «свого шейпера» — шейпера на мості (bridge/linux), з використанням хеш-таблиць. Для великої кількості клієнтів, для великої кількості IP адрес.

Отже, мені треба було написати щось своє.

Я собі спростив задачу:

  1. Хай його всі сварять — я використовуватиму django.
  2. Поєднувати в одній схемі «службові» («кістякові») та «клієнтські» класи здалося заважким — вирішив зробити інакше: для генерування «кістяка» шейпера використовуватиметься окремий скрипт, а для конфігурування (генерування відповідного скрипта) клієнтських класів зроблю собі GUI.

Мій шейпер (тм,-) використовує хеш-таблиці; ці таблиці створює вищезгаданий «окремий скрипт», а заповнюються вони вже скриптами, які генеруються автоматично, засобами django, через специфічні представлення даних.

Отже, «схема» містить такі сутності:

» Читати далі — скрипт і коментарі… »

(No Ratings Yet)

Alt–введення символів у Linux — як у Windows, але краще

Як вводити символи за допомогою цифрової клавіатури під Linux.

Взято звідси: Use Windows «alt codes» in Linux but better, by Lord Matt.

На думку автора, користувачам, які полишили Windows та «мігрували» під Linux, найбільше бракує можливості вводити різні символи з допомогою цифрової клавіатури. Хто не знає — під Windows можна вводити символи, утримуючи клавішу Alt та увівши код символа: наприклад, щоб ввести довге тире, треба тримати Alt і натиснути 0151 на цифровій клавіатурі (символ з’явиться після відпускання Alt).

Ctrl+Shift+u

Отже, подібним чином можна вводити символи і під Linux — для цього треба натиснути Ctrl+Shift+u, на місці курсора побачити підкреслену літеру u («unicode»), ввести код потрібного символа і пробіл (символ з’явиться після натискання пробілу).

Приємно, що можна вводити десяткові та шістнадцяткові значення, здається також html-коди — поекспериментуйте.

2153 дає ⅓, bb — », 468 — Ѩ, 10e0 — რ, 30dc — ボ, bf5 — ௵ і тому подібне.

Де шукати символи? Ну, по-перше, у вашої системи завжди є «Таблиця символів» чи щось подібне, але там мало символів :-) а от на сайті unicode.org (http://unicode.org/charts/) знайдете «повний набір» таблиць символів, які можуть знадобитися.

(No Ratings Yet)

HTB/8021q: Це була моя помилка

Щодо проблеми із HTB шейпером 802.1Q трафіка на linux bridge — це була моя помилка :-)

Я спитав у community@lists.altlinux.org, мене напоумив Sergey Vlasov — дуже дякую!-)

Як сказав Сергій, «передача пакетов в модуль bridge выполняется раньше, чем обработка модулем 8021q». Через це класифікатор просто відкидає пакет як невідповідний фільтру — бо у фільтрі сказано «protocol ip», а ми маємо «protocol 802.1q». Схоже, що достатньо вказати «protocol 802.1q» — після цього адреси (зміщення ві дпочатку пакета IP) «відраховуються» правильно.

Це дає можливість на комутаторах будувати «агрегаційні» шейпери, які оброблятимуть у клієнтських класах пакети клєнтів незалежно від «напрямку» (від належності до певної віртуальної мережі). Причому міграція зі «звичайного» шейпера на комутаторі потребуватиме мінімальних зусиль — треба буде замінити у конфігураторі шаблон «protocol ip» на «protocol 802.1q» (або ж додати ще один фільтр — якщо це справді необхідно).

(No Ratings Yet)

Проблема з HTB шейпером 802.1Q трафіка на linux bridge

Увага: жодних проблем з vlan у класифікатора немає, то була моя помилка.

Експериментував і на трапив на таку проблему: не спрацьовує u32 classifier для «міченого» трафіка на лінукс-комутаторі.

Детальніше:

Полігон для тестування:

Маємо три лінукси. На одному з них (SW) робимо двопортовий комутатор, на інших (BoxA та BoxB) чіпляємо адреси 172.17.2.10/24 та 172.17.2.11/24, наприклад.

Спершу перевіряємо, що на кросовому шнурку BoxA може пінгати BoxB і навпаки.

» Читати далі — скрипт і коментарі… »

(No Ratings Yet)

Останні публікації

Most Rated

Highest Rated

Теґи

Архіви