Správa procesov, ladiace direktívy a virtuálni hostitelia

linux_server.jpg V pre­doš­lej čas­ti sme sa za­obe­ra­li mo­dul­mi, ich pri­pá­ja­ním a opí­sa­li sme, na čo slú­žia jed­not­li­vé mo­du­ly. Vy­svet­li­li sme si, čo sú to kon­taj­ne­ry a kon­tex­ty, na čo slú­žia a ako sa vy­tvá­ra­jú. No a na­ko­niec sme sa zmie­ni­li o po­dmie­ne­ných di­rek­tí­vach. Zos­tá­va nám po­sled­ná časť z kon­fi­gu­rá­cie HTTP server­a, a to sprá­va pro­ce­sov, la­dia­ce di­rek­tí­vy a nas­ta­ve­nie vir­tuál­nych hos­ti­te­ľov.

Sprá­va pro­ce­sov
Beh HTTP server­a je v po­dsta­te služ­ba, a te­da pro­ces. Keď­že na zá­kla­de na­šich zna­los­tí pred­pok­la­dá­me, že je­di­ný pro­ces by asi nes­ta­čil us­po­ko­jo­vať po­tre­by na­šich klien­tov, mu­sí byť spus­te­ných via­cej pro­ce­sov. A tie tre­ba spra­vo­vať. V pô­vod­nom návr­hu webo­vé­ho server­a NCSA server na us­po­ko­je­nie via­ce­rých po­žia­da­viek vet­vil pro­ce­sy. To však pred­sta­vo­va­lo väč­šiu zá­ťaž pro­ce­so­ra po­čí­ta­ča pri prá­ci server­a a ma­lo to zá­važ­ný do­sah na rých­losť je­ho reak­cie. Do­kon­ca bo­lo mož­né za­hl­tiť ce­lý sys­tém pro­ces­mi HTTP dé­mo­nov. Apac­he po­uží­va iný prís­tup. Pri boo­to­va­ní a spus­te­ní HTTP server­a je spus­te­ná sku­pi­na pro­ce­sov server­a. Mô­že­me sa o tom pres­ved­čiť prí­ka­zom ps.

Za­daj­me prí­kaz

 [root@ru­bin root]# ps ax|grep httpd

A na vý­pi­se uvi­dí­me sku­pi­nu prí­ka­zov httpd:

 2554 ?        Ss     0:00 /usr/sbin/httpd
 2628 ?        S      0:01 /usr/sbin/httpd
 2629 ?        S      0:01 /usr/sbin/httpd
 2630 ?        S      0:01 /usr/sbin/httpd
 2631 ?        S      0:01 /usr/sbin/httpd
 2632 ?        S      0:01 /usr/sbin/httpd
 2633 ?        S      0:01 /usr/sbin/httpd
 2634 ?        S      0:01 /usr/sbin/httpd
 2638 ?        S      0:01 /usr/sbin/httpd
 6023 ?        S      0:01 /usr/sbin/httpd
10122 ?        S      0:01 /usr/sbin/httpd
  752 ?        S      0:01 /usr/sbin/httpd
18468 ?        S      0:00 /usr/sbin/httpd
 5238 pts/2    R+     0:00 grep http

Všet­ky pro­ce­sy tej­to sku­pi­ny zdie­ľa­jú pra­cov­nú zá­ťaž. Ak sú všet­ky stá­le pro­ce­sy httpd v čin­nos­ti, spus­tia sa ďal­šie náh­rad­né pro­ce­sy (po­tom­ko­via), kto­ré pre­vez­mú časť zá­ťa­že. Spô­sob sprá­vy po­tom­kov pro­ce­sov server­a je ria­de­ný pia­ti­mi voľ­ba­mi v kon­fi­gu­rač­nom sú­bo­re httpd.conf. Sú to tie­to voľ­by:

- Min­Spa­re­Servers – de­fi­nu­je mi­ni­mál­ny po­čet ne­čin­ných pro­ce­sov server­a, kto­ré mu­sia byť spus­te­né a udr­žia­va­né. V kon­fi­gu­rá­cii dis­tri­bú­cie Red­Hat a Fe­do­ra je voľ­ba nas­ta­ve­ná na 5, čo je vý­cho­dis­ko­vé nas­ta­ve­nie, po­uží­va­né v dis­tri­bú­cii Apac­he. To­to nas­ta­ve­nie za­is­ťu­je, že pri po­kle­se ne­čin­ných pro­ce­sov server­a httpd pod po­čet 5 je vy­tvo­re­ný no­vý pro­ces, aby sa za­cho­val ich mi­ni­mál­ny po­čet. Ak server čas­to rea­gu­je po­ma­ly z dô­vo­du vy­so­kej ak­ti­vi­ty, nas­ta­ví­me Min­Spa­re­Servers na vy­ššiu hod­no­tu.
- MaxSpa­re­Servers – de­fi­nu­je maximál­ny po­čet ne­čin­ných pro­ce­sov server­a, kto­rý mô­že byť udr­žia­va­ný. V kon­fi­gu­rá­cii dis­tri­bú­cie Red­Hat a Fe­do­ra je voľ­ba nas­ta­ve­ná na 20. Po­čas ná­ra­zo­vej ak­ti­vi­ty mô­že byť vy­tvo­re­ných nie­koľ­ko pro­ce­sov httpd, aby sa po­sta­ra­li o po­žia­dav­ku klien­tov. Keď ak­ti­vi­ta opad­ne, prej­dú tie­to pro­ce­sy do ne­čin­nos­ti. To­to nas­ta­ve­nie za­is­ťu­je, že pro­ce­sy bu­dú ukon­če­né, po­kiaľ po­čet ne­čin­ných bu­de viac ako 20.
- Star­tSer­vers – de­fi­nu­je po­čet stá­lych pro­ce­sov httpd, spus­te­ných pri boo­to­va­ní sys­té­mu ale­bo štar­te httpd server­a. V kon­fi­gu­rá­cii dis­tri­bú­cie Red­Hat a Fe­do­ra je voľ­ba nas­ta­ve­ná na 8.
- MaxClients – de­fi­nu­je maximál­ny po­čet klien­tov, kto­ré mož­no na­raz ob­slu­ho­vať. Po­žia­dav­ky nad tým­to li­mi­tom sú za­ra­de­né do fron­tu, kým nie je server dos­tup­ný. V kon­fi­gu­rá­cii dis­tri­bú­cie Red­Hat a Fe­do­ra je voľ­ba nas­ta­ve­ná na 256. Voľ­ba MaxClients za­bra­ňu­je server­u vy­užiť všet­ky sys­té­mo­vé pros­tried­ky li­nuxové­ho server­a, keď dos­ta­ne oh­rom­né množ­stvo po­žia­da­viek od klien­tov. V prí­pa­de, že na náš server sa pra­vi­del­ne kon­tak­tu­je viac klien­tov a my už ne­má­me dos­ta­tok sys­té­mo­vých pros­tried­kov, je lep­šie pri­dať ďal­ší server než pre­ťa­žo­vať li­nuxový stroj. V prí­pa­de ne­dos­tat­ku sys­té­mo­vých pros­tried­kov by to­tiž moh­li zly­hať iné li­nuxové služ­by na da­nom server­i.
- MaxReques­tsPer­Child – de­fi­nu­je po­čet po­žia­da­viek klien­tov, kto­ré mô­že je­den po­to­mok spra­co­vať, než je ukon­če­ný. V kon­fi­gu­rá­cii dis­tri­bú­cie Red­Hat a Fe­do­ra je voľ­ba nas­ta­ve­ná na 4000. Tá­to voľ­ba sa po­uží­va vte­dy, keď ope­rač­ný sys­tém ale­bo kniž­ni­ce ma­jú prob­lé­my s únik­mi pa­mä­te, spô­so­bu­jú­ci­mi prob­lé­my pre stá­le pro­ce­sy. Nas­ta­ve­ním voľ­by MaxReques­tsPer­Child na hod­no­tu 0 (nu­la), t. j. bez ob­med­ze­nia, ur­čí­me, že po­to­mok mô­že spra­cú­vať po­žia­dav­ky po ce­lý čas be­hu sys­té­mu.
- User a Group de­fi­nu­jú UID a GID, te­da vlas­tní­ka a sku­pi­nu, pod kto­rý­mi sku­pi­na pro­ce­sov HTTP dé­mo­nov beží. V pros­tre­dí Red­Hat a Fe­do­ra je to pre obe po­lož­ky Apac­he. Keď sa spúš­ťa sys­tém, ro­di­čov­ský pro­ces sa spus­tí s prá­va­mi roo­ta. Nás­led­ne sa spus­tí sku­pi­na po­tom­kov s prá­va­mi User a Group ako Apac­he. Tým sa webo­vé­mu server­u da­jú čo naj­men­šie sys­té­mo­vé prá­va. V iných dis­tri­bú­ciách je to User aj Group ako no­bo­dy.

Di­rek­tí­vy na la­de­nie vý­ko­nu
Vý­kon kon­krét­ne­ho server­a vždy za­ují­ma správ­cov, kto­rí dba­jú o to, aby ich server bol efek­tív­ny. Aj v HTTP server­i Apac­he exis­tu­je nie­koľ­ko veľ­mi dô­le­ži­tých di­rek­tív, po­mo­cou kto­rých mô­že­me vy­la­diť server tak, aby bol dos­ta­ču­jú­ci pre po­tre­by na­šich klien­tov. Len čo zis­tí­me, že klien­ti sa sťa­žu­jú na po­ma­losť náš­ho server­a, mu­sí­me pris­tú­piť k nas­ta­ve­niu ale­bo po­zme­ne­niu týc­hto la­dia­cich di­rek­tív:

- Kee­pA­li­ve – tá­to di­rek­tí­va za­pí­na ale­bo vy­pí­na po­uži­tie tr­va­lých pri­po­je­ní. Bez tr­va­lé­ho pri­po­je­nia mu­sí klient vy­ko­nať no­vé pri­po­je­nie k server­u pre kaž­dú po­žia­dav­ku, kto­rú má. Pre­to­že služ­ba http beží na pro­to­ko­le TCP, kaž­dé pri­po­je­nie po­ža­du­je nas­ta­ve­nie pri­po­je­nia. Tým sa predl­žu­je do­ba sprís­tup­ne­nia strán­ky (sú­bo­ru). Zo stá­lym pri­po­je­ním server pred je­ho ukon­če­ním ča­ká, či ne­má klient ďal­šie po­žia­dav­ky. Klient pre­to ne­mu­sí pri po­žia­dav­ke na no­vý do­ku­ment vy­tvá­rať no­vé spo­je­nie.
- Kee­pA­li­ve­Ti­meout – tá­to di­rek­tí­va de­fi­nu­je po­čet se­kúnd, po­čas kto­rých server udr­žu­je pri­po­je­nie a ča­ká, či klient ne­má ďal­šie po­žia­dav­ky.
- MaxKee­pA­li­ve­Requests de­fi­nu­je maximál­ny po­čet po­žia­da­viek, kto­ré mož­no pri­jať v prie­be­hu jed­né­ho „udr­žia­va­né­ho“ pri­po­je­nia, než bu­de tre­ba vy­tvo­riť no­vé pri­po­je­nie TCP. Vý­cho­dis­ko­vá hod­no­ta je 100.
- Ti­meout de­fi­nu­je po­čet se­kúnd, po­čas kto­rých server ča­ká na do­kon­če­nie pre­no­su. Hod­no­ta mu­sí byť dos­ta­toč­ne vy­so­ká, aby vy­ho­vo­va­la veľ­kos­ti sú­bo­rov, ak je však pri­vy­so­ká, mô­že server udr­žo­vať pri­po­je­nie pre klien­tov, kto­rí sa už mož­no od­po­ji­li. Ro­zum­ná hod­no­ta je päť mi­nút, te­da 300 (se­kúnd).
- Browser­Match je troc­hu od­liš­ný typ la­dia­ce­ho pa­ra­met­ra. Je­ho úlo­hou je zní­žiť vý­kon­nosť z dô­vo­du kom­pa­ti­bi­li­ty. V dis­tri­bú­cii Red­Hat a od­vo­de­ných je ob­siah­nu­tých týc­hto päť di­rek­tív Browser­Match:

Browser­Match "Mo­zil­la/2" no­kee­pa­li­ve
Browser­Match "MSIE 4\.0b2;" no­kee­pa­li­ve downgra­de-1.0 for­ce-res­pon­se-1.0
Browser­Match "RealPlayer 4\.0" for­ce-res­pon­se-1.0
Browser­Match "Ja­va/1\.0" for­ce-res­pon­se-1.0
Browser­Match "JDK/1\.0" for­ce-res­pon­se-1.0

Tie­to di­rek­tí­vy „prek­la­da­jú“ in­for­má­cie spô­so­bom kom­pa­ti­bil­ným s mož­nos­ťa­mi rôz­nych webo­vých preh­lia­da­čov. Nap­rík­lad niek­to­rý star­ší preh­lia­dač je schop­ný spra­cú­vať iba pro­to­kol http 1.0, a nie nov­ší http 1.1. V ta­kom prí­pa­de sa na riad­ku Browser­Match po­uží­va po­lož­ka downgra­de-1.0, aby server pri ko­mu­ni­ká­cii s tým­to ty­pom preh­lia­da­ča po­uží­val iba pro­to­kol http 1.0. Zá­ro­veň pa­ra­met­rom no­kee­pa­li­ve pre kon­krét­ne preh­lia­da­če vy­pne­me udr­žo­va­nie tr­va­lé­ho pri­po­je­nia. Všeo­bec­ne sa od­po­rú­ča, aby sa s tý­mi­to nas­ta­ve­nia neh­ra­lo. Sú vy­la­de­né po­dľa skú­se­nos­tí vý­vo­já­rov Apac­he a aká­koľ­vek neu­vá­že­ná zme­na by moh­la pri­niesť ne­fun­kčnosť pre niek­to­ré ty­py klien­tov.

Po­sky­to­va­nie webo­vé­ho pries­to­ru iným po­uží­va­te­ľom
Je dob­ré, keď náš li­nuxový server beží iba pre na­še po­tre­by, ale veľ­mi čas­to sa stá­va, že po­tre­bu­je­me náš webo­vý pries­tor po­skyt­núť iným po­uží­va­te­ľom. Exis­tu­jú dve mož­nos­ti. Ak ide o na­šich lo­kál­nych po­uží­va­te­ľov, nap­rík­lad v ško­le ale­bo v ne­ja­kej fir­me, a ná­zov ich webo­vé­ho pries­to­ru bu­de vy­chád­zať z náš­ho náz­vu, mô­že­me po­užiť lo­kál­ny prís­tup po­mo­cou di­rek­tí­vy User­Dir. Ak chce­me po­skyt­núť webo­vý pries­tor s úpl­ne iným náz­vom, po­uži­je­me prís­tup po­mo­cou vir­tuál­nych hos­ti­te­ľov.

Lo­kál­ny prís­tup
Pred­stav­me si, že v na­šej fir­me či ško­le má­me po­uží­va­te­ľa s náz­vom mior, kto­rý by ces­tou náš­ho webo­vé­ho server­a Apac­he chcel zve­rej­niť svo­je osob­né strán­ky. Nech náš server má inter­ne­to­vú ad­re­su zná­mu ako www.ce­va­ro.sk. Po­tom po­uží­va­te­ľo­va inter­ne­to­vá ad­re­sa bu­de mať tvar www.ce­va­ro.sk/~mior.

Ak os­tat­ní po­uží­va­te­lia za­da­jú iba zá­klad­nú ad­re­su www.mior.sk, zob­ra­zí sa im úvod­ná strán­ka náš­ho server­a. Ak však za­da­jú ad­re­su s prí­po­nou /~mior , te­da www.ce­va­ro.sk/~mior, zob­ra­zia sa im osob­né strán­ky po­uží­va­te­ľa mior. Toh­to do­siah­ne­me po­mo­cou di­rek­tí­vy User­Dir.

User­Dir
Tá­to di­rek­tí­va umož­ňu­je po­uži­tie osob­ných po­uží­va­teľ­ských webo­vých strá­nok a uka­zu­je na ad­re­sár, v kto­rom sú ulo­že­né. Bý­va zvy­kom, že di­rek­tí­va User­Dir uka­zu­je na ad­re­sár pub­lic_html. Z toh­to nas­ta­ve­nia vy­plý­va, že po­uží­va­te­lia si vo svo­jich do­mov­ských ad­re­sá­roch vy­tvo­ria ad­re­sár pub­lic_html, do kto­ré­ho si ulo­žia svo­je osob­né strán­ky. Keď po­tom v preh­lia­da­či za­dá­me ad­re­su nap­rík­lad v tva­re www.ce­va­ro.sk/~mior, tá­to po­žia­dav­ka sa na­ma­pu­je na ad­re­su www.ce­va­ro.sk/ho­me/mior/pub­lic_html.

Al­ter­na­tí­vou je de­fi­ní­cia ab­so­lút­nej ces­ty, nap­rík­lad /ho­me/user­pa­ges v di­rek­tí­ve User­Dir. Správ­ca server­a po­tom vy­tvo­rí da­ný ad­re­sár /ho­me/user­pa­ges a umož­ní kaž­dé­mu po­uží­va­te­ľo­vi do po­dad­re­sá­rov uk­la­dať osob­né inter­ne­to­vé strán­ky. Po­tom po­žia­dav­ka na www.ce­va­ro.sk/~mior je na­ma­po­va­ná na www.ce­va­ro.sk/ho­me/ho­me­pa­ges/mior. Vý­ho­dou toh­to prís­tu­pu je zvý­še­nie bez­peč­nos­ti vďa­ka jed­no­duc­hšej kon­tro­le ob­sa­hu osob­ných strá­nok. Správ­ca server­a tiež mô­že jed­no­duc­hšie za­med­ziť niek­to­rým po­uží­va­te­ľom vy­sta­viť svo­je osob­né strán­ky.

Vir­tuál­ni hos­ti­te­lia
Webo­vý server Apac­he po­dpo­ru­je tak­zva­ných vir­tuál­nych hos­ti­te­ľov, čo zna­me­ná, že jed­na in­štan­cia Apac­he (te­da je­den je­di­ný Apac­he na jed­nom po­čí­ta­či) mô­že od­po­ve­dať na po­žia­dav­ky sme­ro­va­né nie­koľ­kým rôz­nym ad­re­sám IP či hos­ti­teľ­ským me­nám tak, ako ke­by týc­hto server­ov bež­alo v sku­toč­nos­ti viac. Kaž­dá z tak­to vy­tvo­re­ných ad­ries IP či kaž­dé z hos­ti­teľ­ských mien mô­že po­sky­to­vať iný ob­sah a mô­že mať úpl­ne inú kon­fi­gu­rá­ciu. Pred­stav­me si te­da, že na na­šom server­i pre­vád­zku­je­me nie­len sku­toč­nú webo­vú ad­re­su www.ce­va­ro.sk, ale chce­me po­sky­to­vať aj ad­re­su www.li­nuxapac.sk. Už z po­hľa­du je zrej­mé, že po­dľa do­mé­no­vých mien ide o dve roz­diel­ne ad­re­sy a mô­že­me oča­ká­vať aj roz­diel­ny ob­sah. Aby sme obid­ve tie­to ad­re­sy moh­li pre­vád­zko­vať na jed­nom a tom is­tom server­i, vy­tvo­rí­me vir­tuál­ne­ho hos­ti­te­ľa.

Naj­prv mu­sí­me v kon­fi­gu­rač­nom sú­bo­re httpd.conf po­vo­liť di­rek­tí­vu Na­me­Vir­tual­Host. Tú­to di­rek­tí­vu od­ko­men­tu­je­me (zma­že­me znak #), prí­pad­ne ur­čí­me ad­re­su, na kto­rej bu­de na­čú­vať, nap­rík­lad

Na­me­Vir­tual­Host *:80

Po­tom mu­sí­me de­fi­no­vať no­vý kon­taj­ner vir­tuál­ne­ho hos­ti­te­ľa, nap­rík­lad tak­to:

<Vir­tual­Host *:80>
       ServerN­am­e www.li­nuxapac.sk    
       Server­Adm­in mior(at)ce­va­ro.sk
       Do­cu­men­tRoot "/da­ta/li­nuxapac"   
</Vir­tual­Host>

Vir­tuál­ny hos­ti­teľ zde­dí z kon­fi­gu­rač­né­ho sú­bo­ru httpd.conf glo­bál­ne nas­ta­ve­nia a svo­ji­mi vlas­tný­mi di­rek­tí­va­mi ich buď dopl­ní, ale­bo po­zme­ní. Hlav­nou di­rek­tí­vou je ServerN­am­e, kto­rá sa nas­ta­ví na www.li­nuxapac.sk. Dru­há dô­le­ži­tá di­rek­tí­va je Do­cu­men­tRoot, kto­rá sa pres­me­ru­je do ad­re­sá­ra /da­ta/li­nuxapac. Sa­moz­rej­me, ten­to ad­re­sár mu­sí­me vy­tvo­riť a do­vo­liť prog­ra­mu Apac­he (te­da po­uží­va­te­ľo­vi a sku­pi­ne Apac­he) prís­tup doň.

Na zá­ver tre­ba eš­te pri­po­me­núť, že je po­treb­né nec­hať nas­ta­viť DNS tak, aby zá­znam v inter­ne­te na ad­re­su www.li­nuxapac.sk po­uka­zo­val na ad­re­su IP ale­bo na me­no náš­ho sku­toč­né­ho server­a www.ce­va­ro.sk. Na­bu­dú­ce sa bu­de­me ve­no­vať bez­peč­nos­ti server­a Apac­he.

Ďal­šie čas­ti >>

Zdroj: Infoware 11/2007



Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

Li­nux prak­tic­ky ako server úvod
Linux ako server je pomerne zložitá technológia. Jej výhodou je určitá modularita, keď sa nemusí nastaviť celý server naraz, ale postupne. čítať »
 
Syn­chro­ni­zá­cia ča­su v Li­nuxe
V predchádzajúcich dvoch častiach sme si ukázali, že Linux a všeobecne open source softvér sa nenachádza iba v serveroch a počítačových sieťach, ale aj v iných zariadeniach bežnej domácej potreby a v oblasti hobby. čítať »
 
Za­ria­de­nia za­lo­že­né na Li­nuxe
V predchádzajúcej časti sme si spomenuli definície nie - ktorých pojmov z oblasti nášho záujmu, teda Linuxu. Vysvetlili sme si, čo je to Open Source, Public Domain, proprietárny softvér a GNU GPL. Tentoraz ukážeme, ako sa tieto pojmy využívajú v praxi. čítať »
 
Po­jmy z ob­las­ti
Tentoraz na chvíľu trochu odbočíme od bezpečnosti Linuxu a jeho siete. V tejto neštandardnej časti seriálu sa mu budeme venovať len okrajovo. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí II.
V predchádzajúcej časti sme sa začali zaoberať bezpečnosťou bezdrôtových sietí. Poukázali sme na rôzne faktory zneužitia siete, podstatu rizika a vysvetlili sme základné prvky bezpečnosti. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí I.
V predchádzajúcich častiach sme sa venovali bezpečnosti linuxového servera. Riešili sme firewall, bezpečnosť prístupu na internet, zaoberali sme sa demilitarizovanou zónou a podobne. čítať »
 
Údr­žba lo­gov – kon­fi­gu­rá­cia log­ro­ta­te
V predchádzajúcej časti sme sa venovali rotácii logov. Vysvetlili sme princíp ukladania logov, spôsob, ako sa rotujú, a uviedli sme niečo o tom, čo a ako treba nastaviť čítať »
 
Údr­žba lo­gov – ro­tá­cia
V predošlej časti sme sa zaoberali spôsobom logovania informácií na iný alebo vzdialený počítač a ukázali sme, ako riešiť problém s logovaním uzavretých procesov pomocou chroot. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter