Мітки: linux

Rspamd уже дав­нень­ко навчив­ся збе­рі­га­ти дані по ста­ти­сти­ці між рестар­та­ми, і от її нако­пи­чи­ло­ся стіль­ки, що роз­див­ля­ти­ся ста­ло ціка­во.

Спад чистих листів напри­кін­ці мину­ло­го року — це я від­пи­сав­ся від об’ємних роз­си­лок GlusterFS і Ceph. Добре видно те, як фільтр навча­є­ться — з часом ростуть обся­ги листів, які вики­да­ю­ться від­ра­зу, а також тих, які грей­лі­стя­ться чи помі­ча­ю­ться як імо­вір­ний спам. Для цьо­го, зві­сно, тре­ба тяга­ти листи з інбо­кса у ката­лог для спа­му.

Зараз в інбокс про­лі­зає мало що, листи помил­ко­во міти­ться спа­мом також дуже рід­ко. Не уяв­ляю, що б я робив без цієї систе­ми філь­тра­ції.

Мітки: ,

Сьо­го­дні ста­ли­ся дві дрі­бно­мас­шта­бні, але дуже при­єм­ні для мене події.

По-пер­ше, мій ігра­шко­вий про­ект по напи­сан­ню аль­тер­на­тив­но­го FUSE-клі­єн­та для кла­стер­ної фай­ло­вої систе­ми GlusterFS тепло сприйня­ли й узя­ли під своє кри­ло роз­ро­бни­ки GlusterFS, і тепер сам про­ект хости­ться в їхній орга­ні­за­ції на GitHub'і. При­йма­ю­ться pull-request'и, я типу голов­на люди­на по цьо­му про­е­кту. Є шан­си, що колись у май­бу­тньо­му ця шту­ка замі­нить добрий шмат коду GlusterFS більш про­стим ріше­н­ням.

По-дру­ге, мій ком­міт упер­ше потра­пив у апстрім ядра, і нова вер­сія 4.6, яка зараз ще пере­бу­ває тіль­ки на ста­дії тре­тьо­го реліз-кан­ди­да­та, мати­ме трі­шки, але без­по­се­ре­дньо моєї пра­ці.

Мітки: , ,

Дав­но я так не грав­ся.

Дано:

  • PBX з одним інтер­фей­сом і дво­ма біли­ми IP-адре­са­ми на ньо­му: 10.0.0.1 як primary і 10.0.0.2 як secondary (сірі адре­си я взяв для при­кла­ду);
  • SIP-про­вай­дер, який дає два різні тран­ки на дві різні IP-адре­си PBX із дво­ма різни­ми облі­ко­ви­ми запи­са­ми, але при цьо­му адре­са піра з боку про­вай­де­ра SIP-тран­ка одна­ко­ва для обох тран­ків і також біла: 192.168.0.1;
  • вели­ке бажа­н­ня різні облі­ко­ві запи­си SIP-тран­ків пуска­ти через окре­мі адре­си PBX, бо у про­вай­де­ра таке security.

Якщо вики­ну­ти зай­вий інфор­ма­цій­ний шум із вві­дних даних, то вияв­ля­є­ться, що ми хоче­мо, щоб один локаль­ний про­цес (Asterisk) під’єднувався до 192.168.0.1:5060 через 10.0.0.1 і 10.0.0.2 зале­жно від того, який облі­ко­вий запис вико­ри­сто­ву­є­ться.

Тоб­то, нам потрі­бен ста­ти­чний L7-мар­шрут (!!!).

Зві­сно, ніякий ip route/ip rule так ніко­ли не зро­бить. Голий iptables — також. Але є одне але.

Ми може­мо обхи­три­ти систе­му і ска­за­ти, що для дру­го­го облі­ко­во­го запи­су SIP-тран­ка Asterisk у яко­сті host має вико­ри­сто­ву­ва­ти не 192.168.0.1, а, напри­клад, 172.16.0.1, і цьо­го разу це має бути будь-яка сіра IP-адре­са. А далі всту­пає в дію махі­на­ція з DNAT/SNAT:

*nat
…
-A OUTPUT -d 172.16.0.1/32 -j MARK --set-xmark 0x10/0xffffffff
-A OUTPUT -d 172.16.0.1/32 -j DNAT --to-destination 192.168.0.1
-A POSTROUTING -m mark --mark 0x10 -j SNAT --to-source 10.0.0.2
…

Тут від­бу­ва­є­ться таке:

  1. тра­фік, який іде на фей­ко­ву IP-адре­су, мар­ку­є­ться яко­юсь міткою (число взя­те зі сте­лі, як, вла­сне, і сіра IP-адре­са);
  2. потім у цих же паке­тах під­мі­ня­є­ться адре­са при­зна­че­н­ня на адре­су піра SIP-тран­ка;
  3. потім за вста­нов­ле­ною рані­ше міткою під­мі­ня­є­ться адре­са від­прав­ни­ка так, щоб тра­фік ішов від іме­ні secondary IP.

Таким чином, увесь тра­фік, який іде на 172.16.0.1, насправ­ді йде на 192.168.0.1, при­чо­му від іме­ні 10.0.0.2.

Вуа­ля — все пра­цює. Без дода­тко­вих інтер­фей­сів, ip route/ip rule, tc (навіть tc уміє NAT, вияв­ля­є­ться) тощо.

Мітки: , ,

У попе­ре­дньо­му запи­сі я роз­по­вів про основ­ні кон­це­пції, які ми вико­ри­сто­ву­є­мо для балан­су­ва­н­ня DNS-запи­тів від клі­єн­тів. Тепер давай­те поди­ви­мо­ся, що змі­ни­ло­ся за чоти­ри міся­ці.
Read More »

Мітки: , , , , ,

Сьо­го­дні я вам роз­ка­жу коро­тку казо­чку про systemd-networkd.

TL;DR: усе пра­цює, але є нюан­си, осо­бли­во в скла­дних кон­фі­гу­ра­ці­ях, тому кра­ще поки вико­ри­сто­ву­ва­ти дистри­бу­тив­ні кон­фі­гу­рял­ки мере­жі.
Read More »

Мітки: , ,

Не мала баба кло­по­ту — пере­с­ета­пи­ла і дома­шній сер­вер з Убун­ти на Арч. Вийшло також дово­лі при­стой­но, хоча з пев­ни­ми осо­бли­во­стя­ми.

Пер­ша осо­бли­вість поля­гає в тому, що за вико­ри­ста­н­ня systemd-networkd для вві­мкне­н­ня фор­вар­дін­гу на інтер­фей­сі тре­ба не забу­ва­ти допи­су­ва­ти IPForward=yes у кон­фі­гах.

Дру­га осо­бли­вість, на пре­ве­ли­кий жаль, гово­рить, що в nftables, зда­є­ться, поки що нема фун­кції clamp mss to pmtu, а також mangle ToS. Ну, це пере­жи­ти поки що можна.

Інші осо­бли­во­сті, начеб­то, були успі­шно прой­де­ні на пер­шо­му пере­с­ета­пле­но­му сер­ве­рі. Тепер у мене зали­шив­ся тіль­ки один бубун­то­сер­вер, але він від мене дале­ко, до того ж, не зов­сім мій, і я не знаю, чи вар­то його вза­га­лі чіпа­ти.

P.S. Я ж був на морі, і все чекаю на фотки від това­ри­шів, щоб хоч якось пока­за­ти, як воно там було.

Мітки: , ,

Як я й обі­цяв, ми випу­сти­ли в opensource балан­су­валь­ник клі­єнт­ських DNS-запи­тів по UDP. Код можна бра­ти тут, під катом тро­хи техні­чних дета­лей.

TL;DR: epoll, SO_REUSEPORT, ldns, pthreads, CRC64+hashtable.
Read More »

Мітки: , , ,

Схо­же, пере­їзд на Арч про­йшов дово­лі вда­ло. Зао­дно я пере­ло­па­тив усі сер­ві­си, які були на ста­ро­му сер­ве­рі, попе­ре­пи­су­вав кон­фі­ги, дещо замі­нив, дещо під­ла­шту­вав. Техні­чні дета­лі для охо­чих наво­жу під катом.
Read More »

Мітки: , , ,

Не секрет, що для осо­би­стих цілей у яко­сті сер­вер­ної пла­тфор­ми я вико­ри­сто­вую Ubuntu. У свій час мене на неї під­са­див Фар­ка­л­лєр, і це справ­ді виявив­ся нор­маль­ний вибір: регу­ляр­ні релі­зи, не про­ту­хший софт, ста­біль­ність, покра­ще­н­ня тощо. Але з вихо­дом 15.04 усе змі­ни­ло­ся — я ще ніко­ли не бачив тако­го сиро­го дистри­бу­ти­ва. Заде­кла­ро­ва­ний пере­хід на systemd вико­на­но щонай­гір­ше: поло­ви­на сер­ві­сів уза­га­лі не кон­вер­то­ва­на, інте­гра­ція з нала­шту­ва­н­ня­ми мере­жі ніку­ди­шня, базо­ві скри­пти ста­ли пада­ти. Я б ще зро­зу­мів, якби це тра­пи­ло­ся на одно­му сер­ве­рі, але якщо на кіль­кох одно­ча­сно — це діа­гноз.
Read More »

Мітки: , ,

Зна­до­би­ло­ся тут вида­ли­ти том GlusterFS, але без того, щоб гро­хну­ти фізи­чно брік. Тре­ба було про­сто звіль­ни­ти на ньо­му місце. На томі жило кіль­ка міль­йо­нів дрі­бних фай­лів, тер­мі­ни піджи­ма­ли, ріше­н­ня «в лоб не було».

У чому загво­зд­ка: GlusterFS на брі­ку орга­ні­зо­вує дані хитрим спосо­бом. По-пер­ше, від­тво­рю­є­ться нор­маль­на стру­кту­ра даних, така ж само, яку бачить кори­сту­вач, коли мон­тує том. По-дру­ге, ство­рю­є­ться під­ка­та­лог .glusterfs, який містить хар­длін­ки на ці фай­ли, ну тіль­ки з інши­ми назва­ми (від­по­від­но до вико­ри­сто­ву­ва­но­го алго­ри­тму хешу­ва­н­ня). Якщо роби­ти тупий rm ‑rf, find . ‑delete чи навіть rsync –delete, то нічо­го хоро­шо­го швид­ко не вийде, оскіль­ки кожний файл буде вида­ля­ти­ся як міні­мум дві­чі (а то й біль­шу кіль­кість разів), і місце на диску звіль­ня­ти­ме­ться тіль­ки після вида­ле­н­ня остан­ньо­го хар­длін­ка кожно­го фай­ла.

Тому в голо­ву при­йшло спо­ча­тку роби­ти truncate:

find . -type f -print -exec truncate --size=0 {} \;

А потім уже роби­ти вида­ле­н­ня пустих фай­лів:

rsync -av -H --progress --delete empty/ folder/

Тіль­ки так можна швид­ко звіль­ни­ти місце за наяв­но­сті кіль­кох міль­йо­нів фай­лів із хар­длін­ка­ми.

Мітки: ,