Üdv,
Két kérdésem is lenne:
#1) Van valamilyen elegáns megoldás arra, hogy adott webszerveren kívánság esetén a különböző kiszolgált domain -ek különböző php.ini fájlt kapjanak?
Konkrét probléma: adott egy webszerver (Ubuntu Server Edition 8.10 64bit + Apache2.2 + php5 + mysql5), rajta több domain (1 domain = 1 weblap). A php exec() függvényét alapesetben szeretném letiltani, viszont van egy speciális, ám megbízható weblap, ami nem képes az exec() nélkül működni...
Olvastam olyasmit, hogy létre kell hozni egy .htaccess fájlt az adott domain documentroot -jának gyökerében és ott megadni neki egy alternatív php.ini -t. De nem találom újra azt a leírást és talán van ennél célravezetőbb megoldás is. (pl. /etc/php5/apache2/conf.d/ -be pakolgatni php.ini -ket domain -enként vagy ilyesmi és talán automatikusan végignézi a php... vagy nem, csak gondolkodom)
#2) Meg lehet oldani azt (és ha igen, hogyan), hogy korlátozva legyen a php mail() függvénye által kiküldött levelek száma? Mondjuk azt szeretném, hogy ne lehessen naponta 500 -nál több e-mailt küldeni egy adott kiszolgált domain -ről. Sőt, azt sem szeretném, hogy egy php -s for (vagy akármilyen) ciklusból 10 -nél több levelet tudjon küldeni a delikvens egyszerre (mondjuk pár másodpercen belül).
Köszönöm előre is a tippeket, ötleteket, javaslatokat, megoldásokat! :)
- 2036 megtekintés
Hozzászólások
1. van -> cgi
2. lehet, pl valami custom made sendmail wrapperrel.
t
- A hozzászóláshoz be kell jelentkezni
Jelenleg "libapache2-mod-php5" van beállítva, szóval nem cgi -ként fut a php... a jelenlegi felálláshoz illeszkedő megoldás esetleg van? :)
- A hozzászóláshoz be kell jelentkezni
nincs.
t
- A hozzászóláshoz be kell jelentkezni
a .htaccess többek között erre is jó, vagy én értek félre valamit?
http://www.askapache.com/php/custom-phpini-tips-and-tricks.html
- A hozzászóláshoz be kell jelentkezni
elméletileg
SetEnv PHPRC /var/www/user/custom-php.ini
(http://httpd.apache.org/docs/2.0/mod/mod_env.html#setenv)
- A hozzászóláshoz be kell jelentkezni
de ez modulos php-vel nem fog menni igy.
t
- A hozzászóláshoz be kell jelentkezni
Nem, a php.ini a libphp betöltésekor, azaz az apache betöltésekor kerül beolvasásra, pontosan egyszer.
Ven egy halom direktiva, amit lehet állitani bármelyik apache confban, pl. minden usernek a home könyvtárára php_value open_basedir "/srv/webhosting/username/:/tmp/:/usr/share/php/", akar .htaccessben is.
Azonban eleg sok php opcio egyaltalan nem allithato. Pl. futtato user (azt orokli az apachetol), vagy a disable_functions amit csakis egyszer az elejen lehet a php.ini-ben beallitani, es utana mindenkire ervenyes lesz. Azaz vagy mindenkinek lesz ra joga a siteon, vagy senkinek sem.
Ha ez nem jo, akkor suphp vagy php-cgi.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
Inkább fcgi
- A hozzászóláshoz be kell jelentkezni
nem arktam ennyire specifikusan, csak egy iranyt probaltam adni.
t
- A hozzászóláshoz be kell jelentkezni
1 Neeeeeeeeeeeeeee... eleg, ha az apacsbol indul mindig +1 peldany lekeresenkent, nem kell meg a php-bol is.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
suPHP -val lehet ilyet
http://www.suphp.org/Home.html
0.2es verzio ota (jelenlegi a 0.7):
Changes in version 0.2(valamikor 2003 ota talan):
- Added support for (de-)activation for each VirtualHost defined in the Apache configuration
- Added support for different php.ini's, configurable in the Apache config
- A hozzászóláshoz be kell jelentkezni
Köszönöm az eddigieket.
Akkor összefoglalva: az #1 -es kérdéssel kapcsolatban 2 választásom van (ami nekem szimpatikus): fastcgi modulként betölteni a php -t (de akkor már használhatnék apache helyet lighty -t vagy nginx -et) vagy suphp (ez jónak tűnik, de érdekelne róla valakinek konkrét tapasztalata, pl. mennyivel kell több erőforrás, stb.)
A #2 -es kérdésemre viszont még nem sikerült értelmeznem az egyszem beérkezett választ (interpriter error) :) Ebben segítenétek kicsit többet? :)
- A hozzászóláshoz be kell jelentkezni
A mail fv-t nem tudod korlatozni. Raadasul van egy halom egyszeru php-s smtp lib, amivel kozvetlenul tud csatlakozni egy SMTP szerverhez.
Ha nagyon muszaly ez (de minek is?), akkor az SMTP szerveren tennem kotelezove az auth-ot es ott korlatoznek.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
muszaj, uszaly
t
- A hozzászóláshoz be kell jelentkezni
Az egyik tárhelyszolgáltatónál tudok ilyen korlátozásról, de azt, hogy hogyan oldotta meg, nem tudom... ezért gondoltam, hogy megkérdezem :)
(ott úgy volt megoldva, ahogy írtam: php mail() függvény volt korlátozva napi x darab mail küldésére)
- A hozzászóláshoz be kell jelentkezni
Szerintem vagy belenyultak a php forrasaba vagy ok is nem a php mail() szintjen, hanem a level kuldo sendmail/smtp szintjen korlatozzak.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
en tudok egyrol (nem nevezem meg) ahol konkretan kicsit atirtak a mail fv forrasat. es ugy forgattak le
- A hozzászóláshoz be kell jelentkezni
pl freeweb
t
- A hozzászóláshoz be kell jelentkezni
2) nezd meg az ssmtp-t azzal tudsz 25-os portra (akar localhostra is) kuldeni levelet, a sendmail binarist erre kell atallitani, es jo lesz neked. Onnantol meg mar a levszerveren tudod szabalyozni, ki hany levelet mikor es hova.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni