Brownian motion

around the essentials…

 

Archive for the Категорія ‘Адміністрування’

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)

Gmail, IMAP та «мітки» кирилицею

Gmail дає змогу чіпляти до листа різні мітки, які з точки зору протоколів витягування пошти (POP3 та IMAP4) є скриньками. В принципі, інтерфейс Gmail також їх показує як скриньки з листами.

Іноді у різних рецептах (згодувати spamassassin’у теку «Спам» із гуглопошти, наприклад) окремим пунктом програми передбачено витягування вмісту такої скриньки (за допомогою fetchmail, скажімо).

Рішення просте:

poll imap.gmail.com protocol IMAP
   user "nouser@gmail.com" is localuser here
   password 'superpassword',
   folder "[Gmail]/Spam",
   # folder 'from Smith',
   # fetchlimit 1, keep,
   ssl

Але проблема виникає тоді, коли мітки українською (не латинкою, взагалі кажучи). І ніде, чомусь, я рішення не знайшов, саме тому це й пишу.

Справа в тому, що кодування назв скриньок має бути у «модифікованому UTF-7»; це зазначено у RFC 3501 (5.1.3. Mailbox International Naming Convention).

При цьому «службові» скриньки зазначаються як «[Gmail]/Скринька»:

poll imap.gmail.com protocol IMAP
   user "nouser@gmail.com" is localuser here
   password 'superpassword',
   folder "[Gmail]/&BCEEPwQwBDw-",         # «Спам» — обов’язково "[Gmail]/"
   # folder '&BDIEVgQ0- &BCEEMARIBDoEMA-', # «від Сашка» —  *без* "[Gmail]/"
   # fetchlimit 1, keep,
   ssl
(No Ratings Yet)

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

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

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

(No Ratings Yet)

Gnuplot — малюємо час на отримання результату від Informix’а

Є Asterisk, через який дзвонить купа клієнтів. Є задача — отримати від сервера Informix (не питайте, бо не знаю) кількість секунд, які певний клієнт може наговорити, дзвонячи на певний номер телефону. Тобто, для спрощення, на сервер іде запит [номерА, номерБ], сервер віддає число (>=0).

При цьому є підозра, що під кінець місяця сервер думатиме довше; є також підозра, що ті клієнти, що більше говорять, довше чекатимуть відповіді.

Хочеться це все якось бачити. Для цього у той скрипт, який бере дані з Informix’а, додаємо двійко рядків, щоб писати журнал, у приблизно такому вигляді:

# час, «номер клієнта», куди дзвонив, залишок секунд, час на отримання
# звісно, всі номери <номерБ> різні:
"2012-04-05 17:29:34.455199","01",<номерБ>",0,"0:00:00.078631"
"2012-04-05 17:46:47.482675","02",<номерБ>",0,"0:00:00.895389"
"2012-04-05 17:48:19.594244","02",<номерБ>",0,"0:00:00.029423"
"2012-04-05 17:53:18.827345","02",<номерБ>",0,"0:00:00.033318"
"2012-04-05 18:02:59.955417","02",<номерБ>",0,"0:00:00.042353"
"2012-04-05 18:05:10.750765","02",<номерБ>",0,"0:00:00.031215"
"2012-04-05 18:05:53.240702","02",<номерБ>",0,"0:00:00.029587"
"2012-04-05 18:06:47.190297","03",<номерБ>",0,"0:00:00.063169"
"2012-04-05 18:56:49.293827","02",<номерБ>",0,"0:00:01.110830"
"2012-04-05 19:03:51.475956","02",<номерБ>",0,"0:00:00.032815"
"2012-04-05 19:42:59.389716","02",<номерБ>",0,"0:00:00.034776"

Так, зараз на всі запити сервер віддає нуль, не зважайте .)

Зверніть також увагу, що у журнал падає, насправді, не 01, 02, 03 тощо, а номер телефону, з якого йшла спроба дзвонити, — але я ховаю номер телефону, ховатиму його й на графіку, і у скрипті нижче для цього буде вжито певних заходів (тобто, це робитиму не я, а awk). Тобто, замість номеру телефону awk підставлятиме «номер клієнта».

На графіку хочемо бачити щось таке (по координаті X буде час):

  • червоними хрестиками — час відгуку;
  • синіми колами — час від попереднього дзвінка;
  • для відгуків > 0.5 секунди біля хрестика писатимемо клієнта;
  • і ще якісь усереднення.

Я нижче поясню, чому це не надто ілюстративно для даної задачі, і що варто було б зробити натомість, але — нижче.

Щоб малювати час від попереднього запиту нам мало цих даних — до кожного рядка треба також додати це значення.

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

Читати далі »»

(No Ratings Yet)

tcpdump: відсіювання HTTP GET

Уявимо себе адміністратором сервера, що перебуває під атакою–відплатою за EX.ua (одразу зауважу, що я не є таким адміністратором, у мене просто гарна уява).

У першу чергу, нам було би цікаво, що саме летить на нас, що саме «валить» наш сайт «із ніг».

Щоб довідатися, є різні способи — скажімо, дивитися журнал веб-сервера, дивитися трафік на сервері утилітою tcpdump чи подібною; можна на проміжному комутаторі відгалужувати трафік і дивитися його tcpdump’ом десь на іншому комп’ютері… Але, так чи інакше, завжди цікаво знайти найбільш універсальний інструмент.

На мій погляд, найбільш універсальним інструментом є саме tcpdump.

Одразу зауважу, що ми можемо «попрохати» tcpdump писати трафік у файл, кожні N секунд закривати файл і починати новий, а на щойно закритому виконувати певну дію (запускати скрипт) — таким чином ми можемо не лише збирати, а й у режимі «майже реального» часу аналізувати інформацію і виконувати певні дії. Це все вміє сам tcpdump, ми маємо лише все продумати і написати скрипти .)

Наприклад, може бути зручним використання утиліти fail2ban; але цей скрипт працює на одному ядрі і на гарно навантаженому сервері (яким, імовірно, є кожен сервер під атакою) почувається невпевнено. Але ми можемо суттєво полегшити йому життя, якщо не змушуватимемо читати журнал веб-сервера, а «згодовуватимемо» вже добре проаналізовану інформацію. Наприклад, із зібраної tcpdump’ом інформації відбирати адреси, з яких надходить більше X [кіло]запитів за одиницю часу.

Отже, tcpdump виглядить («має вигляд» — «виглядить», а не «виглядає»!) досить зручним інструментом. Тож спробуємо з його допомогою ловити лише HTTP GET пакети.

А тепер зазирнемо у нутрощі пакетів »

(1 votes, average: 5 out of 5)

«Малювалка» трафіку на Пітоні

Свою малювалку трафіку (читай тут) я трохи «заребрендерив» — тепер це SPy Bulk Grapher, або ж SPyBG!-) — і виклав git-сховище на github’і: SPyBG.

Сталося це тому (я ж бо ніколи про це якось і не думав), що виникло бажання дописати деякі можливості, а це буде зручніше робити з нормальним керуванням кодом, з розгалуженнями тощо — а думка зробити сховище публічним (не на bitbucket.org, скажімо) вже й не дискутувалася :О)

(No Ratings Yet)

Making RtConfig (IRRToolSet) in Ubuntu

Having used IRRToolSet in elder Ubuntu releases (elder compilers, libraries etc), i finally decided to compile it under 9.10 (yes, previously made RtConfig works under 9.10 too, «but anyway»).

But something goes wrong, with several files — illegal conversion and «bad» syntax and the like.

So, if you’ll run into the same problems, hope this patch will help.

Apply patch as usually (in the directory where IRRToolSet-4.8.5 is unpacked):

$ patch -p0 --dry-run < IRRToolSet-4.8.5-ubu-patch.diff

If everything is OK, remove --dry-run switch and run again.

(No Ratings Yet)

Django-based HTB shaper configurator

I’ve decided to make it available after some nice people asked for this.

Now i have no time and, let’s say, health to make it better, so please don’t complain :-)

I guess it maybe would be better to make it available somewhere at code.google.com — i would like to work on this code later, surely.

Anyway. Now — as it now is. With incomplete README:

» Читати далі… »

(2 votes, average: 5 out of 5)

Шейпер як ефективний файрвол

Шейпер із використанням хеш-таблиць може досить ефективно захищати клієнта від атак; ось дивіться.

Зараз наш конфігуратор шейпера генерує, скажімо, такий скрипт для певного клієнта (фрагмент):

#
# Contract I-1082,
# connection 606 (0x25e).
#
# input:
/sbin/tc class add dev clients0 classid 1:25e parent 1:fe10 htb rate 96kbit ceil 128kbit quantum 1500 burst 7500 cburst 12500 prio 50
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5c match ip dst X.X.133.92 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5d match ip dst X.X.133.93 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5e match ip dst X.X.133.94 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5f match ip dst X.X.133.95 flowid 1:25e

Припустимо, з адреси 173.204.53.138 іде атака на X.X.133.94 — купа якихось пакетів, багато, весь канал клієнта забитий. (Так, адреса реальна, була реальна атака,-)

Все, що нам треба, — вписати потрібний фільтр у потрібну комірку хеш-таблиці:

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

(No Ratings Yet)

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

*subj* :-)

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

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

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

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

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

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

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

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

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

(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

Теґи

Архіви