ugrás a tartalomhoz

Paraméterek Apache és PHP összehagolásához - szakdolgozat védésemhez

tiku I tikaszvince · 2005. Jún. 7. (K), 14.32
A címben olvasható kérdésre kell válaszolnom a szakdolgozatom védésekor (pénteken).
Végiggondoltam, és arra jutottam, hogy elmondom, hogy httpd.conf -ban ott van az AddType, meg megemlítek a php.ini-ből néhány fontosabb beállítási lehetőséget (register_globals, display_error, error_reporting)... de itt elakadtam.
Kérnék néhány öttletet, mimindent lenne még érdemes megemlítenem?
Köszi
TikuVoltam
‹ teljes latogatottsagi statisztika meres Rejtett belepes ›
 ■
1

telepítés, beállítás

bbalint · 2005. Jún. 7. (K), 15.01
  • php.ini állomány (hol lehet megtalálni, általában - /etc/php.ini; C:\%windir%, szerver könyvtárja)
  • php_flag, php_value különböző konfigurációs részekben (httpd.conf, .htaccess; hogyan lehet megcsinálni pl azt, hogy csak a valami.hu doménen legyen bekapcsolva a register_globals)
  • plusz php.ini a PHPINIDir direktívával (sok beállítás módosítása esetén hasznos)
  • néhány beállítást a PHP programokból is lehet módosítani (ini_set()), de pl a magic quotes futás-idejű beállításához külön függvény is vala
  • parancssoros felületen (CGI SAPI, ami nem túl jó megoldás apache esetén) is lehet módosítani a beállításokat a d kapcsolóval:
  • végül az éppen érvényes beállításokat, hogy lehet ellenőrizni (ini_get(), phpinfo())
php -d register_globals=on

végig a PHP beállításáról kell beszélni; nem lehet(ne) esetleg a telepítésről, kapcsolódási módokról (SAPI-k: apache, apache2, CGI) is szót ejteni?

eddig milyen ,,fontosabb beállítási lehetőségeket'' kívánsz fölsorolni?

bbalint
2

ezekre gondoltam

tiku I tikaszvince · 2005. Jún. 7. (K), 15.26
Én eddig ezekre gondoltam:
  • register_globals
  • display_error, error_reporting
  • max_execution_time
  • post_max_size
  • default_mimetype

Bár már (lehet hogy a fáradtság miatt, vagy mert már vagy százszor elolvastam a kérdést) egyre kevesebb értelmet vélek benne felfedezni. Már az is felmerült bennem hogy teljesen rosz irányba indultam el.
Ugye nem? :'(
3

rizs

bbalint · 2005. Jún. 7. (K), 17.11
ha "el lehet térni a tárgytól", tehát pl nem közvetlenül belevágsz, hogy ,,ha ezt írja át az ember a php.ini-ben, akkor az történik, hogy ...'', hanem kell/kötelező/érdemes valami bevezetőt is összehordani, akkor nyugodtan lehet kezdeni az apache-val, hogy mi is az, mi az alapja, milyen verziói vannak, mire jó, stb
ugyanígy bevezetni a PHP-t aztán belevágni a felsorolt PHP beállíthatósági lehetőségekre, aztán PHP beállítások, hogy mit érdemes állítgatni ...
register_globals-nál fel lehet hozni példát is, hogy miért is rossz, éshogy mégis miért használták/használják sokan.

én még megemlíteném a a következőket:
  • engine - PHP kikapcsolása (apache konfig)
  • short_open_tag - <? nyitó tag-ek (T_OPEN_TAG) engedélyezése
  • asp_tags - <%, vagyis ASP-stílusú nyitó tag-ek
  • output_buffering - kimenet-pufferelés bekapcsolása minden PHP elején; itt lehet szólni, hogy ilyenkor pl az egész PHP-ban lehet nyugodtan HTTP fejléceket kírni (header() és setcookie())
  • safe_mode - szafaládé (najó: safe mode)
  • open_basedir - könyvtár lekorlátozása (nemcsak szafaládé módban; azt eredményezi, hogy csak az itt megadott könyvtárba' levő filékkel lehet dolgozni)
  • disable_functions, disable_classes - további korlátozások; a 'biztonság' szó megemlítésével, meghogy pl milyen függvényeket szokás letiltani (exec(), phpinfo(), ftp_connect())
  • expose_php - annyira nem fontos, de biztonsági szempontból igen: látszódjon-e a Server(?) HTTP fejlécben, hogy PHP van (biztonság)
  • memory_limit - linuxon alapértelmezésben nincs memória-korlátozás, windowson viszont igen
  • max_execution_time, max_input_time - max. végrehajtási és a bejövő adatok max. feltöltési ideje
  • error_reporting - milyen hibaüzeneteket mutasson alapból; milyen alapértéken van? miért érdemes E_ALL-ra állítani inkább? (velem volt néhányszor, hogy egy nem definiált változóval bajlódtam több időt)
  • magic_quotes_gpc - bejövő adatok escape-elése, időt vesz/vehet el fölöslegesen (én nem szeretem; megcsinálom akkor, ha kell - *_escape_string() a *_query()-ben)
  • include_path - include*()/require*() függvényeknél hol keresgélje a megadott file nevét
  • extension_dir - kiterjesztések helye
  • file_uploads, upload_max_filesize, post_max_size - file feltöltésekor ezeket vesz figyelembe PHP
  • allow_url_fopen - ftp://, http://, stb:// filék megnyitásának engedélyezése (biztonság)
  • SMTP, sendmail_path - mail() levélküldéshez
felsoroltam sokt, válogass. lehet, erről sokkal többet lehet és érdemes beszélni.

csak a PHP beállíthatásáról kell/lehet majd beszélned, vagy a "mellékes" témákról (apache, PHP története, telepítése) is?

bbalint
4

csak ami a címben van

tiku I tikaszvince · 2005. Jún. 7. (K), 17.42
A bírálatot tegnap kaptam meg, és csak a címben szereplő kérdés van rajta. Plusz kismillió szempont amit 1-5ig kellett osztályoznia a bírálónak.
A kérdésből kiindulva, meg hogy nem kell csak 5-8 percet beszélni erről a kérdésről, azt hiszem, hogy a történeti dolgokat hanyagolhatom.
Arra gondoltam, hogy egy rövid bevezetőben (ami természetesen kell) ecsetelem, hogy a biztonsági kérdéseknél mikre kell odafigyelni. A "gyári" beállítások milyen veszélyeket rejthetnek magukban, valamint, hogy a paranoiás rendszergazdák mikkel szórakozhatnak még. :)

  • engine? - erre kiváncsi lennék (bár biztos, hogy a műveletlenségemről teszek nyilatkozatot).
  • short_open_tag + asp_tags - na ez az a két beállítás aminek nem látom semmi értelmét. pontosabban az értelmét látom, de nem bírom elékpzelni, hogy valaki is használja. Szóval feleslegesnek érzem
  • open_basedir, disable_functions, disable_classes - a paranoiás rendszergazda esete :)
  • error_reporting - na ez nekem is nagy segítség szokott lenni...


Amúgy hogy őszinte legyek, magát a kérdést is egy kicsit sántának érzem. Csak azért mert én "összehangolni" olyan dolgokat szoktam amik nem jönnek ki egymással teljes mértékig. Az Apache PHP viszont szerintem egész jól megvannak már elég régen.
Plusz még a paraméterezés biztos hogy ugyanazt jelenti mint beállítás? Mert az én szóhasználatomban a beállítás egyszeri, központi, tevékenységet jelent. Míg a paraméterezés a feladatnak (környezetnek, könyvtárnak) megfelelő beállításokat, melyekkel eltérek a központi beállításoktól.
Csak hogy érthető legyek: a böngészőmnek megmondom, hogy ha elindul akkor mi legyen a kezdőoldal. Ez egy beállítás. De ha egy másik program azt mondja neki, hogy ezt az URL-t mutasd, akkor az egy paraméter.
Ezek miatt, is érzem hogy rosz irányba indultam el.
5

ö

bbalint · 2005. Jún. 7. (K), 19.15
hát, ha nem kell hosszan értekezni a dologról, akkor oké.

engine - ez a zopció arra való, hogy mondjuk globálisan be van töltve a PHP, de mondjuk egy <VirtualHost/>-on vagy egy <Directory/> könyvtárban nem szeretnéd, hogy még véletlenül is lefussanak a PHP-k, akkor ott csak egyszerűen annyit kell mondani, hogy
php_flag engine off
bár... az az érdekes, hogy az AddType direktíva (a dokumentáció szerint) majd' mindenhol használható ...

short_open_tag - sok forráskódban (amit láttam) csak rövid nyitó tag-et (<?) tesznek, nem pedig rendeset (<?php, <script language="php">), ami mindenhol működik
asp_tags - ez nemcsak az ASP stílusú nyitó tag-eket (<%) engedélyezi, de az ASP stílusú kiiratást is:

<?='Hello'?>, <%='világ'%>!
és ilyet is használnak többek.

az open_basedir pedig inkább a félparanoiás rendszergazdák esete; pl elég csak beletenni egy pontot és a PHP már csak a vele egy szinten vagy a vele egy könyvtárban levő filéket tudja birizgálni:

[php]
open_basedir='.;~' ; mondjuk ez itt konkrétan a felhasználó könyvtárát is engedi
szerintem, ennyi bőven elég (lenne) egy-egy PHP hosting helyre ...

hát, szerintem paraméterezni... meghatározni paramétereket, hogy milyen korlátok között működjön a dolog.
az is lehet, hogy meg kéne említeni, hogy a fejlesztői gépen milyen beállításokat javasolsz, míg a rendes szerveren milyen korlátozásokat érdemes bevezetni.

a kérdés pontosabb jelentésére nem lehetne rákérdezni? vagy felvázolni a te elméleted, hogy te a beállításokra gondoltál és hogy az helyes-e?

bbalint
6

jó ötlet

tiku I tikaszvince · 2005. Jún. 7. (K), 19.24
a kérdés pontosabb jelentésére nem lehetne rákérdezni? vagy felvázolni a te elméleted, hogy te a beállításokra gondoltál és hogy az helyes-e?

Ez egy naggyyon jó ötlet! küldök is egy mailt a bírálónak
TikuVoltam
7

a válasz

tiku I tikaszvince · 2005. Jún. 8. (Sze), 10.51
Na, a közös gondolkodást (amiért riszpekt forevör) elősegítendő, megjött a válasz. A tanári értelmezésben arról van szó, hogy a dolgozatomban nem tértem ki a webszerver és adatbázis szerver telepítésre. Csak a PHP programom telepítését fejtem ki.
arra próbál utalni, hogy hiányzik a dolgozatból a rendszer telepítésének (beüzemelésének) a leírása: hogyan kell összelőni a komponenseket

Ennek fényében úgy gondolom, hogy a scriptem futásához fontos beállításokat fogom kicsit kivesézni. Ezek pedig
  • httpd.conf, .htaccess - bár ebben a két dologban (főleg .htaccess) nagyon nem vagyok otthon
  • php.ini állomány,
  • register_globals,
  • error_reporting (E_ALL)

Majd még azt kell kiderítenem, hogy hogy lehet egy scriptet (vagy inkább a webszervert?) úgy belőni, hogy csk a belső hálózatból, intranetről legyen elérhető. Gondolom a htaccess környékén kell majd nézelődnöm.
TikuVoltam
Ma is holnap fekszünk le, mint tegnap
8

htaccess

bbalint · 2005. Jún. 8. (Sze), 16.50
én úgy tudom, hogy htaccess-ba nem lehet mindent belefelé írni (ServerRoot meg ilyesmik)
viszont lehet <Directory/>, <Location/>, <Files/> és egyéb részeket beletenni, a httpd.conf-ban elhelyezett AllowOverride-nak megfelelően.

helyi hálózatra meg pl úgy lehet korlátozni, hogy
  • tűzfallal lekorlátozni, hogy csak bizonyos IP-ről jöhessen be csomag/kapcsolat
  • httpd.conf-ban megadni, hogy pl csak a 192.168.1.1:80 címen és porton halgatózzon az apache (Listen)
  • ha be van töltve "valamilyen" (mod_access) modul, ami tartalmazza az Allow meg Deny utasításokat, akkor azokkal úgy, hogy:

Allow from 192.168.1.
  Deny from All
  Order allow,deny

így, elvileg csak a 192.168.1. kezdetű IP-kről lehet jönni.

bent munkahelyen én inkább a PHP-val ellenőrzöm a dolgot, mer' mér' ne ...
lehet inkább majd megtanulok tűzfalul és majd úgy szűröm ki a nem kívánt IP-ket.

.htaccess hátránya, hogy ha engedélyezve van, akkor "mindenhol" keresgéli az apache, minden lekérésnél, ezért lassú lehet a dolog, hogy pl /e/b/b/e/a/k/o/n/y/v/t/a/r/b/a/v/a/g/y és olyankor az összes fentebb levő könyvtárba keres .htaccess :-(

én fejlesztéskor .htaccess-be bele teszem a dolgot, de amikor éles szerverre kerül ki, inkább a httpd.conf-ba vagy .vhost filébe átírom.

bbalint
9

Köszönet a segítségért

tiku I tikaszvince · 2005. Jún. 11. (Szo), 00.38
Köszönök szépen minden segítséget!
Sikerült megvédenem a szakdolgozatomat 5-ösre :)

TikuVoltam
Ma is holnap fekszünk le, mint tegnap
10

kösz

bbalint · 2005. Jún. 11. (Szo), 01.29
végül tényleg ilyen beállításokról kellett beszélned?
miről kérdeztek végül?

bbalint
11

másról

tiku I tikaszvince · 2005. Jún. 11. (Szo), 08.22
Addigra kicsit más formában tették fel a kérdést. Arról kellet beszélni, egy picit, hogy milyen fejlesztő környezetet használtam. Mivel már elég későn kerültem sorra, éhesek voltak, pörgeték az egészet, nem is hagyták hogy rátérjek beállításokra.
TikuVoltam
Ma is holnap fekszünk le, mint tegnap