cron, exec, többiek
Előre bocsátom: fejlődési céllal érdeklődök, nincs (sajnos) konkrét probléma, időben is ráér.
Amin gondolkodom, keresgélek:
Sok írásban olvastam, hogy
-
Mi van, ha nincs cron? És mégis kell vmi hasonló. Gondolnám én bután(?): amikor jön a Júzer, megkapja az oldalát, közben exec a cron helyett, abban a progiban meg benne az ellenőrzés, hogy kell-e már futni, v. exit. Ilyenkor ugye, nem lassítottuk a Júzer kiszolgálását a karbantartási (pl. DB-mentés) műveletek miatt. (Erre a kérdésre nem kérek ilyen választ: "másik tárhely kell".)
- Mi van, ha olyan (hosszú futásidejű) programrészt kell futtatni, ami "eseményvezérelt", tehát bizonyos felhasználói beavatkozás következménye, és nem ad vissza közvetlen kimenetet (pl. csak cache-be dolgozik, de rögtön)? Ilyen esetben én favágásnak érezném a pl. percenkénti cron-t ("fájl-kommunikációval"), ha a kiváltó esemény csak kb. hetente van, de nem tudni pontosan. Viszont a proginak meg hamar futni kell, mert mittomén. Gondolom, szolgáltatók azt se szeretik, ha percenként ketyeg egy-két-... cron, még ha csak néhány feltétel erejéig is.
Lehet, ez így zavaros, a ()-es pl-k sem túl életszerűek, de szeretném tudni, hogy mire valók
Illetve azt is olvastam (talán Janoszen tollából), hogy biztonságtalan is így futtatni progit. Miért, milyen veszélyek vannak? Hogyan lehet (lehet-e) biztonságosan?
Aki ráér, kérném szíves véleményét!
■ Amin gondolkodom, keresgélek:
Sok írásban olvastam, hogy
exec()-et és társait messziről kerülni, u.azt a dolgot inkább cron-nal, ezeket a fv.-et inkább letiltani php.ini-ben, stb. DE:-
Mi van, ha nincs cron? És mégis kell vmi hasonló. Gondolnám én bután(?): amikor jön a Júzer, megkapja az oldalát, közben exec a cron helyett, abban a progiban meg benne az ellenőrzés, hogy kell-e már futni, v. exit. Ilyenkor ugye, nem lassítottuk a Júzer kiszolgálását a karbantartási (pl. DB-mentés) műveletek miatt. (Erre a kérdésre nem kérek ilyen választ: "másik tárhely kell".)
- Mi van, ha olyan (hosszú futásidejű) programrészt kell futtatni, ami "eseményvezérelt", tehát bizonyos felhasználói beavatkozás következménye, és nem ad vissza közvetlen kimenetet (pl. csak cache-be dolgozik, de rögtön)? Ilyen esetben én favágásnak érezném a pl. percenkénti cron-t ("fájl-kommunikációval"), ha a kiváltó esemény csak kb. hetente van, de nem tudni pontosan. Viszont a proginak meg hamar futni kell, mert mittomén. Gondolom, szolgáltatók azt se szeretik, ha percenként ketyeg egy-két-... cron, még ha csak néhány feltétel erejéig is.
Lehet, ez így zavaros, a ()-es pl-k sem túl életszerűek, de szeretném tudni, hogy mire valók
exec() és társai, ha mindenki cron-t mond helyette?Illetve azt is olvastam (talán Janoszen tollából), hogy biztonságtalan is így futtatni progit. Miért, milyen veszélyek vannak? Hogyan lehet (lehet-e) biztonságosan?
Aki ráér, kérném szíves véleményét!
MySQL
Köszi,
Kompromisszum
Ilyenkor kompromisszumos megoldás van, ami nem szép, de alkalmanként hasznos.
Nálam volt ilyen, napi mentést kellett megoldani cron nélkül.
1. Készült egy .php script, ami megvalósítja a mentést, emlékeim szerint mysqldump-ot exec-el.
2. Az oldalba (ami amúgy egy fórum motor) bekerült egy feltétel, hogy ha a lapletöltés időpontja nagyobb mint 23:00, akkor beinclude-olja a dumpoló scriptet.
3. Ha dump script elindul, megnézi hogy aznap készült-e már backup.
4. Ha még nem, akkor csinál egyet, aztán eldobja a három napnál régebbieket, hogy ne foglalja a helyet. Ha aznap már volt backup, akkor nem csinál semmit.
A buktatók:
- Feltételezi, hogy az oldalnak van olyan látogatottsága, hogy minden nap 23:00 és 24:00 között van legalább egy látogatója.
- Amíg a dump fut (2-3 perc), addig ott áll a végrehajtás, a user meg homokórát lát
- A mysqldump lockolja a DB-t, így a backup alatt minden arra tévedő user homokórát lát.
A megoldás messze van az ideálistól, de mivel nem business critical szolgáltatásról van szó, a célnak pont megfelelt.
Ha érdekel részletesen, később tudok mutatni kódot is hozzá.
A buktatók:… többsége
Köszi!
Lehet nem eléggé jól fogalmaztam meg a kérdést, sőt, valószínű. Az is lehet, hogy csak én vagyok ilyen "desktop-os" szemléletű (múltú), de talán a kérdésem lényege az, hogy felhasználó által kiváltott esemény hatására akarok elindítani a háttérben (=nem homokórázó) futó progit, aminek nincs közvetlen HTML kimenete.
Az is lehet, hogy a weben ilyen "nincs", csak én vagyok ilyen "eseményvezérelt"... Legalábbis erre következtetek abból, hogy válaszaitok is azt tükrözi, amit/amiket máshol is olvastam.
Szóval: hagyjam a fenébe? Vagy vmilyen cron, vagy lófütty?
felhasználó által kiváltott
De végül is ha az exec()-el indított parancsot háttérbe küldöd és a kimenetét átirányítod, akkor a PHP szkript nem várja meg és nincs homokóra:
Lásd lentebb
Ezen felül a másik probléma, amire Kayapo kolléga felhívta a figyelmemet, hogy SELinux alatt van olyan opció, ami az ilyen renegát processzeket kilövi egy idő után.
Köszönöm a választ,
exec()függvénnyel? Mert ha igen, akkor ez:exec(), akkor nem homokórázik, csak a DB miatt, nem? Viszont hainclude(), akkor a "lap végén" fut a szkripted, tehát nincsexec().Nem.
A mindenféle execről a POSIX (Linux, Unix, stb) értelmében:
POSIX platform alatt az exec függvény forkol egyet, majd a gyerek szálba betölti a végrehajtani kívánt programot. A szülő szálból megkapod a gyerek input/output/error descriptorát, amivel tudsz vele kommunikálni. Ha a szülő processz terminál (pl. az Apache úgy dönt, hogy azt a szálat újra kell indítani), akkor az általad indított folyamat az inithez kerül (adoptálja). Ez önmagában nem probléma, de ha egy rendszergazda lát egy levegőben lógó processzt, biztos lehetsz benne, hogy a következő mozdulata az lesz, hogy kilövi a fenébe, mert nem tudja kideríteni, honnan szalajtották. Ez kb így fog kinézni:
janoszen 3533 0.0 0.0 14656 852 ? S 20:12 0:00 \_ gnome-pty-helper
janoszen 3534 0.0 0.1 30564 5592 pts/0 Ss+ 20:12 0:00 \_ bash
janoszen 3632 0.1 0.1 30564 5568 pts/1 Ss 20:15 0:00 \_ bash
janoszen 3770 0.0 0.0 22344 1248 pts/1 R+ 20:17 0:00 \_ ps auwfxx
janoszen 3768 0.0 0.0 96332 3568 pts/0 S 20:17 0:00 php forktest.php
Van helye
Az exec-kel az a legfőbb probléma, hogy az, aki használja, legtöbbször nem érdi a Linuxos processz modellt, jogosultsági rendszert és ezért majd csodálkozni fog, ha instabil vagy biztonsági hibás lesz az alkalmazás. Tipikusan ilyenek azok is, akik azzal magyarázzák az exec használatát, hogy valamiféle admin panelt írnak.
Röviden és tömören a lényeg: az exec nem való frontendet kiszolgáló alkalmazások alá. Kizárólag külön jogosultsági szinten futó, API-val megszólítható rendszerekre. Egész egyszerűen azért, mert több szinten kell védekezni és ha egyetlen védelmed van (az escapelés a parancssorban), akkor egy abban felfedezett hiba az EGÉSZ alkalmazás vagy szerver biztonságát veszélyeztetheti. Nem az a kérdés, hogy talál-e valaki code execet, hanem hogy mikor. Láttam már jó pár ilyet és mindig okosnak hitte magát a programozó.
Köszönöm szépen
(Egyébként egyik ami a gondolkodásra idított: egy neked is "elég ismerős" szolgáltatónál 3 tárhelycsomag közül csak a legdrágább ad cron-t. De nem ez volt a lényeg, mert ahova cron kell, oda az a csomag kell és kész. Évi 3-5 e Ft különbségért nem szabad gányolással "pótolni", ez eredetileg is véleményem volt.)
Mégegyszer köszönöm.
Értéknövelt
Hajrá cikk!
Azt a FastCGI-s cuccosodat (ha egyre gondolunk) nemigazán értem (még), nem is akarnék "ügyeskedni"; az ottani középső csomagból - számomra és egyelőre - csak a cron hiányzik. Később valószínű, hogy kihasználnám a további "extra" szolgáltatásokat is, de az már másik honlap, megrendelő, stb. lenne. Nem is olyan rég csináltam egy honlapot, ahol még DB sincs, de összesen két "főnök" számára kiküldött heti email van (naplórészlet, stb.). Tehát nagyon egyszerű honlap esetében is könnyen "befigyel" a kihasználatlan tárhely/szolgáltatás. Mondjuk ez sem egetverő, mert az itt-meg-nem-nevezett szolgáltatónak szerintem elég jó árai vannak.
(A DB nélküli honlap egy drágább helyen van, és ott csak a tárhelyméret több - feleslegesen -, viszont sok más szempontból rosszabb.)
Cikk