Run cron if load < X and uptime > Y only

Linux-haladó

Sziasztok,

Nem megfelelő a rendszeremen számomra a cron ütemezése. Bizonyos feladatoknál az alábbira van szükségem:

Csak akkor induljon el bizonyos ütemezés, ha a loadavg 15 perces értéke adott érték alatt van, illetve ha a suspend-ből felébredés óta eltellett minimum idő, pl. 1 óra.Példa (Ruby): 

#!/usr/bin/env ruby

# get load average for last 15 min
n1 = File.read("/proc/loadavg").split[2].to_f

# get time passed since boot
n2 = File.read("/proc/uptime").split[0].to_f

# get time passed since last resume from suspend
require "time"
t1 = `journalctl -b 0 -o short-iso`.split("\n")
if t1.size > 0
	t2 = t1.grep(/system resumed/i)[-1]
	if t2
		t3 = t2.split[0].to_s
		if t3 != ""
			n2 = Time.now - Time.parse(t3)
		end
	end
end

p n1, n2

exit  (n1 < 0.1 and n2 > 3600)

Itt van két értékem mihez tudok hasonlítani és ha csinálok rá egy parancsot (ifidle) akkor így futtatnám:

ifidle fstrim ...
ifidle snapper cleaup ...
...

Ki hogyan csinálná? Tovább tudjátok gyúrni?

Az egész egyébként a btrfs transaction futása miatt kell, mert snapper-t használok sok snapshot-tal és időnként takarítania kell, ami rosszkor fut - ugye itt nagy I/O keletkezik és megáll a rendszer 5 percre és pont rosszkor, mert wakeup után sietek munkával és azonnal reagálni akarok dolgokra.

Kösz.

( log69 | 2017. 10. 30., h – 10:55 )

És mi a legmegfelelőbb módja a cron átírásának (hourly, daily, weekly) figyelembe véve hogy egy update felülírhatja akármikor?

Az /etc/cron.[hourly|daily|weekly] alá tett scripteket nem írja át semmi update. Viszont te nem biztos, hogy azt akarod, mert azok ált az anacronhoz tartoznak, és arról szólnak, hogy mindenképp fusson, mikor a gép online lesz legközelebb.

Sima /etc/crontabot se nagyon fog neked semmi kérdezés nélkül felülcsapni, mert arról azért minden épkézláb distró tudja, hogy config, de arra is az /etc/cron.d/ alá tenni a cronjobokat a legtisztább talán (vagy izlés szerint valami user crontabjába, ha van dedikált service user. Mondjuk én ezt nem preferálom, vannak bajai)

persze, csak egyrészt a kontextuson itt azért látszik, hogy nem hiányzik a plusz hibaforrás, a fenének se hiányzik, hogy túrni kelljen a mindenféle shelleket, amik néha az ilyen spec userekbe be vannak drótozva, aztán vagy átszivárog épp a passwdből, vagy nem, másrészt meg sok olyan elvileg jól megírt scriptet láttam én, amivel mégiscsak volt gond.

Szóval természetesen lehet azt jól csinálni, csak én szerintem egy csomó fölös tényezőt behoz, úgy, hogy igazából nincsen többnyire added value benne. Ráadásul azt tapasztalom, hogy egyszeri turkálós ember a crontabba meg a cron.d-be még csak belenéz, a /var/spool/cronba már ritkábban, ezért én személy szerint jobban szeretem az egységesebben (nem)működő cron.d-t, de mint mondtam, ez alapvetően preferencia kérdése, ha valami értelmes ok miatt jobb a service user crontabjába (pl mert login shellből működik csak normálisan valami obskurus cmd, és ott úgyis karban tartja valaki, ami kell neki, vagy akár csak ott épp az a szokás) szívbaj nélkül oda írom.

A binugzhuszároknak persze, hogy vixiet :-) a tennyerük a crontab -e parancs kiadásakor... Egyébként a sysvinit-et is lehet jól csinálni... Ja, hogy binugzosoknak az sem ment...? Scriptet írni egyszerű. Jól megírni egy scriptet nem annyira - ugyanis mindenki azt hiszi, hogy mivel egyszerű, man meg a csilliom rosszul-rosszabbul tákolt netes példa alapján sima ügy - miközben nem.
Tízből kilenc (és fél) scriptben nincs trap, pedig kéne. Nincs mindenre kiterjedő, sőt szinte semmilyen hibakezelés. Nincs explict megadott, a scripten belül érvényes PATH, illetve egyéb, a futás szempontjából lényeges környezeti változó megadva. A mindenféle shellfüggő trükköket mosty nem veszem ide - azt a megfelelő shellt megadva a futtatáshoz még azért lehet tolerálni.
Az added value mondjuk bőven elég, ha annyi, hogy az user legyalulásával az időzített folyamatai is mennek a levesbe, mindenféle szívfájdalom nélkül. No meg az, hogy PAM-mal szépen lehet szabályozni, hogy melyik user használhat cron-t és melyik nem - aki meg igen, az önállóan meg tudja csinálni, nem kell emelt szintű jogosultságot adni neki a közös lónak túros héta cron fájlhoz, vagy épp könyvtárhoz a /etc alatt.

Ha valami csak a login shellből működik, az nagyjából környezeti változótól függést jelent - némi logikával ki lehet sakkozni, hogy mi kell neki, oszt' jónapot... Jó, persze, a "test -t 1" is bekavarhat :-P

"A binugzhuszároknak persze, hogy vixiet :-) a tennyerük a crontab -e parancs kiadásakor... Egyébként a sysvinit-et is lehet jól csinálni... Ja, hogy binugzosoknak az sem ment...? Scriptet írni egyszerű. Jól megírni egy scriptet nem annyira - ugyanis mindenki azt hiszi, hogy mivel egyszerű, man meg a csilliom rosszul-rosszabbul tákolt netes példa alapján sima ügy - miközben nem.
Tízből kilenc (és fél) scriptben nincs trap, pedig kéne. Nincs mindenre kiterjedő, sőt szinte semmilyen hibakezelés. Nincs explict megadott, a scripten belül érvényes PATH, illetve egyéb, a futás szempontjából lényeges környezeti változó megadva. A mindenféle shellfüggő trükköket mosty nem veszem ide - azt a megfelelő shellt megadva a futtatáshoz még azért lehet tolerálni."

"Ha valami csak a login shellből működik, az nagyjából környezeti változótól függést jelent - némi logikával ki lehet sakkozni, hogy mi kell neki, oszt' jónapot... Jó, persze, a "test -t 1" is bekavarhat :-P"

Mondtam én mást? Már a binugzozáson túl? Annyit mondtam, hogy a komplexitások egy része ott kevésbé kavarnak be, ha nem jól megírt a script. Az egyébként már nagyon offra visz, de szépen felvezetted, miért szar eszköz a shell az ilyen feladatokra. :) Sokkal többet kell foglalkozni a shell lelkének ápolgatásával, mint a saját problémád megoldásával. Nyilván a világ hülye, hogy állandóan szar shell scripteket ír mindenki.

"Az added value mondjuk bőven elég, ha annyi, hogy az user legyalulásával az időzített folyamatai is mennek a levesbe, mindenféle szívfájdalom nélkül"

Én legyalulni csomagból / config managementből szoktam, az remekül el tudja takarítani az /etc/cron.d -be rakott filet. (ha meg kézzel vakarok oda valamit, akkor igen, esélyes, hogy adott esetben én is a user cronjába rakom, de ez a kivétel)

"No meg az, hogy PAM-mal szépen lehet szabályozni, hogy melyik user használhat cron-t és melyik nem - aki meg igen, az önállóan meg tudja csinálni, nem kell emelt szintű jogosultságot adni neki a közös lónak túros héta cron fájlhoz, vagy épp könyvtárhoz a /etc alatt."

Hát, multi user környezetben ez igaz, mentségemre legyen mondva, service userről volt szó, az ritkán írja maga a crontabjait, és települni meg úgyis valami értelmes priviledggel rendelkező telepíti. Ráadásul ott meg egyébként security szempontból jobb az, hogy a sokszor eleve /bin/false shelles user, amire a deamon majd ráül nem kap egy kiskaput, hogy ha megnyomják a szolgáltatást, akkor a cronon keresztül tudjon shellscriptet indítani.

Nem az eszköz szar, hanem a tudatlan "azt hiszi, hogy tud shellscriptet írni" péhápépistike szinvonalat is alulról vizslató wannabe linuxhuszár hozzáértése. És sajnos ez elég sokszor jellemző a "gyári" csomagokba pakolt scriptek elkövetőire is.
Nem a shell lelkének az ápolhgatásával, hanem a helyesen tervezett, a szükséges feltételeket önmagában beállító/vizsgáló, korrekt hibakezeléssel bíró program írásával kell foglalkozni. Jaaaa... Hogy ezt sokan nem tudják megugrani, mint feltételt...? Próbálj meg Java-ban mindent try/catch nélkül (de tényleg mindent!) lekódolni úgy, hoogy minden körülmények között működjön. Na a shellscriptek jelentős része ilyen...
Mondom, lehet shell-ben is jó kódot írni, csak az kellően munkás dolog, mint bármelyik más nyelven. Működőt könnyebb (mind minden más nyelvben), és sokan megálllnak ott, hogy "oké, most működik", de ha rákérdeznek, hogy az a 23. sor az micsoda, akkor az a válasz, hogy passz, de ha az nincs ott, akkor nem jó :-P

"Nem a shell lelkének az ápolhgatásával, hanem a helyesen tervezett, a szükséges feltételeket önmagában beállító/vizsgáló, korrekt hibakezeléssel bíró program írásával kell foglalkozni."

Jaja, mint pl hogy van e space a kiba = két oldalán. Mondom, mindenki hülye, csak a shell helikopter :) Nem mondtam, hogy nem lehet benne helyesen működő programot írni (perlben is lehet pl olvashatót, csak ahogy kolléga mondani szokta, nem szokás), azt mondtam, hogy szerintem sokkal többet kell kerülgetni a shell saját bajait, mint máshol. A shell egy elég vacak programnyelv.

Ráadásul tipikus usecase az a pár soros integráció, ami aztán mint mondtad is köszönettel legalább egy oldal, ha az ember tényleg normálisra akarja csinálni. Az adminok jó része meg nem programozó, szóval erre bizony nem egy jó tool. (Figyelj, ettől még a user lehet, hogy péhápápistike, és ez nem menti fel, de azt sem, aki nem ehhez igazodó toolt ad a kezébe).

Értem, hogy téged ez triggerel, mert szereted a shellt, de légyszi fogadd el, hogy más meg esetleg nem. :)

Space or not space... Mondd, mi a véleményed a python-ról? :-P Az értékadást shell-ben úgy írjuk hogy valami=akarmi, space nélkül. Ha valaki ezt nem tanulja meg, az mennyivel rosszabb, mintha más nyelv alapvető szabályait felejtené el alkalmazni? És igen, itt is vannak finomságok, például számként a 08 meg a 09 esete, de ilyenek máshol is előfordulnak :)
Hülyebiztos programnyelv nem nagyon van - a futás feltételeit meg kell teremteni a kódban, a hibákat vizsgálni/kezelni kell mindenütt - van, ahol egyszerűbb, van, ahol kevésbé. A shellekben egészen jól megvalósítható mindez - igen, ismerni kell azt, hogy mit hogyan csinálunk, és talán mégjobban azt, hogy mit hogyan nem csinálunk shell-ben.
Az, hogy egy script milyen hosszú, nem igazán problémás - ha van egy jó "keret", ami a számára szükséges dolgokat beállítja/ellenőrzi, kezeli a script kilépésekor/megszakításakor szükséges dolgokat, akkor a lényeges részt nem kunszt megírni.

Még mindig ízlésről próbálsz vitatkozni velem. :) A pythont meg szeretem, in practice a leading space probléma sokkal kevésbé idegesítő (figyelj, számomra) mint pl az egyenlő körüli spacek. (és ja, vannak ott is vicces szívásfaktorok, kedvencem pl a "def foo(bar=[])" ).

A boilerplate viszont igenis probléma. Szegény java architectemet is szénné trollkodtam, mindig, mikor örült, hogy milyen sok már a generált kód, hogy most annak örül, hogy a javaban ennyi szart kell fölöslegesen kiírni? :D De viccet félre, a boilerplatet pl karban is kell tartani, abban is lehet hiba, azt propagálni kell mindenhova, ahol használtad stb. És pl egy perl/python/akármi izénél tipikusan nem kell mondjuk a signal handlinggal foglalkozni, mert köszöni, jó úgy ahogy van. (Illetve ott 99.5%ban jó úgy, nem annyiszor kell(ene) hozzányúlni.

( uzsolt v | 2017. 10. 30., h – 11:04 )

Mi lenne, ha inkább az IO-igényes parancsodat nice vagy ionice segítségével futtatnád?

Gondoltam rá, de szerintem nem segítene, mert itt a kernel space-ben futó [btrfs-transacti] folyamat veszi el az összes I/O-t és nem tudom hogy nem-e joggal - vagyis nem olyan feladatot csinál-e amíg tényleg meg kell állítani minden hozzáférést az FS-hez. Erről nem találtam infót.

Tehát a snapper-t hiába rakom alacsony nice-ra, az gyorsan végez kitakarítva a snapshot-okat, miután egy idő után elindul a kernel oldali fs és elkezd takarítani.

Nincs quota nálam. Szerintem az van hogy az FS sok feature-t tud egy "sima" Ext-hez képest amelyek komplikálttá teszik és a snapshot takarítást nem tudják egyelőre megcsinálni másképp. Ezért célzom a fenti workaround-ot ami megoldja nálam a kérdést, de azért kutatom hogy van-e jobb megoldás.

Hát ja, ez elég csúnya workaround: hiszen az, hogy a feléledéstől mondjuk 1 órával hamarabb nem fogja elvégezni ezt a műveletet, nem ad semmi garanciát arra, hogy amikor csinálja, pont akkor nem kellene sürgősen a gép.

A legjobb szinte az lenne, ha feldobna egy párbeszédablakot, amelyben megkérdi, hogy az elkövetkezendő 5 percben tudod-e nélkülözni a gép használatát (persze mondjuk 10 másodperc múlva automatikusan az "Igen" lenne :) ).

Linux desktop éve, 2017 (bocs, nem tudtam kihagyni :) ).

:)

Hogy ne rosszkor induljon el 1 óra múlva, az első felvetésem hivatott kiküszöbölni, vagyis hogy figyelem a terhelés mértékét és csak alacsonynál engedem. Tehát egy trendet nézek - persze itt is lehet hogy pont akkor kell, de ha a tendencia üres járatot mutat, ott sokkal nagyobb az esély hogy magra van hagyva a gépem, ellentétben azzal mikor nagyon hektikus a felhasználás.

( kroozo v | 2017. 10. 30., h – 12:54 )

egyébként a most növesztett megoldásod miért nem jó? cronból ütemezed a scripted, aztán az max skippeli az adott runt, ha épp nem idle a gép.

( gabrielakos v | 2017. 10. 30., h – 12:57 )

Nem kell különösebben átírni a crontabot, megírod ezt a scriptet úgy, hogy return status akkor legyen nulla ha minden oké.
És akkor úgy néz ki a cronjob sor, hogy:

ifidle && fussonez

S ha éppen nemoké a futás akkor nem fog futni.

--
Gábriel Ákos

( hnsz2002 v | 2017. 10. 30., h – 14:15 )

"ugye itt nagy I/O keletkezik és megáll a rendszer 5 percre"
Hát ebből látszik, hogy a btrfs a zfs nyomában sincs.... Egy snapshot törlésnek kb. pár másodpercnek kéne lenni.
--
"Sose a gép a hülye."

Simán lehet jobb ZFS, régebb óta többen tolják a szekerét és talán nagyibb is lehet a user base, elfgoadom. Viszont nekem egy ideje jól muzsikál BtrFS. Ennyi a gondom vele. Remélem figyelnek majd erre a jövőben és jobban szétosztják a szükséges erőforrását a folyamatnak vagy okosabb megoldást tudnak alkalmazni.

Meghát ugye én használok több snapshot-ot, tehát azt is elfogadom hogy valamit valamiért. Bottleneck mindig van, kérdés hogy milyen feltételek mellett jön elő és milyen sűrűn :)

( golgota | 2017. 10. 30., h – 14:36 )

Hat modjuk erre vannak a monitorozo rendszerek. Figyelnek, majd ha threshold van, akkor futtatnak egy handlert/action-t, stb.

En felraknek egy standalon modu sensu-t es azzal utemeznem a check-et, majd egy handler lefutna ha baj van. Vagy ugyanezt barmilyen monitorozoval ami kepes a check+handler funckiora (nagios es forkjai, stb)

( log69 | 2017. 11. 12., v – 13:20 )

Megnéztem a dolgokat és úgy döntöttem, maradok a saját megoldásnál.

Végül úgy alakítottam a script-et, hogy ne eldöntse hogy most jó-e a cron job futása és annak függvényében indítsa a parancsot vagy ne (command && command2 ..), hanem várjon addig amíg üresjáratba kerül a gép.

Ez azért jobb, mert az előbbi esetben lehetne olyan, hogy sok napig nem kerül futásra a daily cron job, mivel lehet hogy pont akkor akar lefutni, amikor nem jó, és ez esetben csak másnap tudna újra próbálkozni. Utóbbi megoldással pedig le fog futni, csak én döntöm el hogy mikor.

Az is jó, hogy így csak egyetlen helyre kell beillesztenem a kódba. Mégpedig a daily cron job fájljának legelejére. Forrás kód:

https://github.com/log69/myscripts/blob/master/ifidle.rb

Nem ugyanez a problema, de en nalam meg az jott elo, hogy periodikus job-ok futtatasanal jo lenne randomizalni a kozoket. Mondjuk 10 perces job idokozonkent barhol lehet 8-12 perc kozott.

Igy a teljesitmenytuskek nem mindig ugyanoda esnek idoben. (nem minden egesz orara pl.).

Egyebkent amit te szeretnel, az olyan, mint az androidoknal van:
egy jobot futasidoben hatterbe lehessen kuldeni es megallitani. Majd legkozelebbi
lehetosegnel feleleszteni, es ott fusson tovabb ahol abbahagyta.

Nem tudom, hogy fajlrendszeres muveleteknel ez mennyire egeszseges.
De teny, hogy akksiido optimalizalas fasorban sincs az androidhoz kepest.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

sleep rand(N) minden Cron hívás előtt nem felel meg?

Ja, biztos hogy jobb Androidon az opt. Jó lenne ha a kernel nézné a felhasználási szokásokat az aktuális terheléssel együtt. Bár eddig csak a BtrFS snapshot clean okozott eddig gondot, mert ez akasztja csak meg a rendszert. Nyilván a többire az ütemező beállítás van, ami eddig megfelelt.

Mondjuk én most a job-ot nem akarom háttérbe küldeni, hanem azt akarom hogy el se induljon ha nem alkalmas. Nem is lenne nagyon bonyolult lefejleszteni. Lehetne egy beállítás egyetlen csúszkával hogy mennyire agresszíven szabályozza a konfliktus elkerülést azt kész. Tárolhatna statisztikát illetve a load is sokat elmondana. Meg ahogy te is írod, bele lehetne venni még egy random faktort.

Lehet kellene fejleszteni egy hasonló egyetlen szál rendszer parancsot, ami vissza ad egy igent vagy egy nem-et meg lenne beállítása az /etc/-n belül illetve lokális user setting a .config-ban (ha elérhető). És a freedesktop spec részévé kellene tenni.

Esetleg systemd plugin? :)

Három napja megy és jelentem, működik. Csak akkor fut le a job, ha nem vagyok gépnél, és hiba nélkül le is fut, "snapper list" szépen kitakarítva.

Ezen felül jó lett az általam 0.5-ös értékre vett 15 perces load, ugyanis a 4 magos i5-ömön úgy néz ki, hogy 0.25 körül mozog ha meg vannak nyitva appok de nem nyúlok a géphez (több mint 15 percig természetesen), és használat alatt (ami netezés, kód gépelést jelent) olyan 1-es körül mozog. VM-ek és játék futtatásánál pedig felmegy olyan 3 körülire.

Így néz ki az utolsó 24 óra terhelése a notimon:
https://i.imgur.com/Tqd2AD4.png

Igen. A [btrfs-transaction] kernel folyamattól megáll és megfagy teljesen minden aminek egy parányi I/O is kellene. Ez lehet hogy a snapshot takarítás természetéből adódik, hogy fel kell addig függeszteni más FS műveletet.

Itt ugye snapshot-ok törléséről van szó konkrétan, amit a snapper clean parancs indít el.

Ugye mivel kernel folyamatról beszélünk, így nem tudsz ionice-ot sem állítani tudtommal.

Nem, ugy emlekszem, hogy 4.10-es kernelen mar nem volt ez.

Mennyi egy snapshot-ot csinalni?

$ time btrfs su create @eee
Create subvolume './@eee'
btrfs su create @eee 0.00s user 0.01s system 27% cpu 0.032 total

$ uname -a
Linux parsec 4.13.0-16-generic #19-Ubuntu SMP Wed Oct 11 18:35:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Sok snapshot egyidejű törlésekor áll be a rendszer. Lesd meg a snapper csomagot. Ez automatikus készít és töröl snpshot-okat, csak ugye egyben törli. Ő kiadja a parancsot, a kernel modul meg elvégzi. Körülbelül pár percre áll be ilyenkor. Szerintem ha csinálsz 15 snapshot-ot és másnap törlöd, akkor lehet nálad is megakad.

Szoktam ilyet csinalni.
En az apt-btrfs-snapshot csomagot hasznalom.
Most pl.:

@apt-snapshot-2017-11-01_07:48:46
@apt-snapshot-2017-11-02_08:10:36
@apt-snapshot-2017-11-02_08:41:02
@apt-snapshot-2017-11-02_14:41:21
@apt-snapshot-2017-11-02_19:23:52
@apt-snapshot-2017-11-03_00:17:15
@apt-snapshot-2017-11-03_00:17:44
@apt-snapshot-2017-11-03_00:18:36
@apt-snapshot-2017-11-03_00:18:47
@apt-snapshot-2017-11-03_00:19:29
@apt-snapshot-2017-11-03_00:19:43
@apt-snapshot-2017-11-03_10:07:40
@apt-snapshot-2017-11-03_22:02:37
@apt-snapshot-2017-11-04_17:41:38
@apt-snapshot-2017-11-04_18:12:43
@apt-snapshot-2017-11-04_18:20:34
@apt-snapshot-2017-11-06_00:23:01
@apt-snapshot-2017-11-06_00:23:13
@apt-snapshot-2017-11-06_20:01:57
@apt-snapshot-2017-11-07_10:10:34
@apt-snapshot-2017-11-07_23:07:15
@apt-snapshot-2017-11-07_23:08:05
@apt-snapshot-2017-11-08_09:33:47
@apt-snapshot-2017-11-08_17:33:39
@apt-snapshot-2017-11-09_08:22:15
@apt-snapshot-2017-11-09_15:43:24
@apt-snapshot-2017-11-09_18:31:16
@apt-snapshot-2017-11-10_08:57:06
@apt-snapshot-2017-11-10_17:53:32
@apt-snapshot-2017-11-10_18:15:54
@apt-snapshot-2017-11-10_20:23:34
@apt-snapshot-2017-11-10_23:15:48
@apt-snapshot-2017-11-11_07:32:00
@apt-snapshot-2017-11-13_19:48:52
@apt-snapshot-2017-11-14_14:32:35
@apt-snapshot-2017-11-14_14:48:43
@apt-snapshot-2017-11-14_19:55:47
@apt-snapshot-2017-11-14_23:57:17
@apt-snapshot-2017-11-15_09:15:33
@apt-snapshot-2017-11-15_19:29:11

Ezen kivul vannak rohadt regi snapshotok is, neha azokbol is torlok. De egyik sem szokta megakasztani a rendszert. Plane nem percekre. Amit fent irtam, az is csak nehany idegesito masodpercre volt. Nem is szabadna szerintem, h ilyet csinaljon. Nekem ez buzlik..:)

Most terhelem bonnie++ cuccal a lemezt, de nem akad. Viszont a [btrfs-transaction] mindig megakasztja. Azt vajon nem lehet finom hangolni nice-al? Ránézek a man page-re.

Szerk.: Sőt, ha a btrfs fájlrendszerű külő USB-s backup vinyómra mentek rsync-kel (ami egyébként dm-crypt-el titkosított plsz réteggel), az is megakasztja. És mikor megnézem iotop-pal, csak a [btrfs-tra...] fut 99% vagy 100%-on.

Szerk.: közben erre kerestem:
https://duckduckgo.com/?q=btrfs+transaction+hang

Van egy ilyen meg hasonlók:
https://github.com/markfasheh/duperemove/issues/167

Szerk.: túrtam a netet, egylőre semmi.