Tegyuk fel, hogy - mivel nem vagy elegedett a vendor altal szallitottal - sajat RPMet csinalsz az Apache httpdbol.
Kerdesek:
- Upstreambol vagy SRPMbol forditanal? Milyen szempontok alapjan?
- Milyen core modulokat raknal bele es miket nem? Miert?
- Az osszes modult egy nagy RPMben szallitanad vagy minden modult kulon RPMbe raknal? Miert?
Nyilvan megvan a sajat velemenyem is, de a tieteket is szeretnem hallani :)
- 4037 megtekintés
Hozzászólások
attól függ, mit akarsz vele elérni...
Az összes kérdésedre az elvárásoktól függően számos -egymástól teljesen eltérő- megoldás lehet az optimális.
pl:
Testre szabott saját konfigot akarsz nagy tömegben teríteni, azonos funkciójú szerverekre, vagy testre szabott saját konfigot akarsz nagy tömegben teríteni több féle feladatot ellátó szerverekre?
- A hozzászóláshoz be kell jelentkezni
A konfiguralas nem problema, az mas eszkozokkel megoldhato.
Szempontok, nem feltetlenul ebben a sorrendben:
- Biztonsag
- Menedzselhetoseg
- Skalazhatosag
- Magas rendelkezesre allas (ez kulon, egybe vagy kotojeles? :))
- Teljesitmeny
- A hozzászóláshoz be kell jelentkezni
Ez így túl általános.
- A hozzászóláshoz be kell jelentkezni
Persze hogy az, hiszen egy ceg sokfele rendszereben sokfele szerepkorben kell jol teljesitenie :)
Ne ugy kepzeld el, hogy mondjuk van egy alkalmazasod es azt terited szet tobbezer szerveren. Ehelyett van 50 ilyen-olyan (php, tomcat, stb) alkalmazasod es ennek szeretnel egy olyan webszervert kesziteni ami az altalanosan kituzott celokat teljesiti.
- A hozzászóláshoz be kell jelentkezni
Na, ez már konkrétabb. :)
"- Milyen core modulokat raknal bele es miket nem? Miert?"
Meg kell határozni az összes olyan core modult, ami mindegyik szerverbe kell.
Ezek mennek bele alapból.
"Az osszes modult egy nagy RPMben szallitanad vagy minden modult kulon RPMbe raknal? Miert?"
Azokat rakom egy RPM-be, amik mindegyik installhoz kellenek. A többit külön. Esetleg, ha lehet csoportosítani a szervereket valami elv alapján, akkor lehet több modult is egy RPM-be pakolni, amiket az adott csoport gépeire mindíg kell telepíteni. (pl. Tomcat-es gépekre a tomcathez szükséges modulokat egybe, stb.)
A miértre a válasz: Optimális esetben minden szerverbe csak azt a modult kell belerakni, amit használni is fogsz. A csoportosítás a kezelhetőség szempontjából fontos, mert ha nagyon elaprózod az egyes modulok telepítőjét (mindent külön rpm-be), akkor nehezebb kézben tartani, mit -hova kell rakni, nagyobb mögöttes adminisztráció szükséges.
szerk:
Ha a milyen "core-modulok..." kérdésnél arra gondoltál, hogy mi az amit belefordítanánk a binárisba, és mi az amit modulárisan lehessen betölteni, akkor pl.:
Bele:
core.c
prefork.c
http_core.c
mod_so.c
Minden mást modulárisra.
- A hozzászóláshoz be kell jelentkezni
"Meg kell határozni az összes olyan core modult, ami mindegyik szerverbe kell.
Ezek mennek bele alapból."
Igen, a kerdes az lenne, hogy te pl miket raknal bele statikusan es miket nem? Reszemrol ezek a mod_access, mod_mime, mod_dir es a mod_log_config. Minden mast disablere es kulon modulba (a coreban nagyon sok az alapbol engedelyezett, de nem feltetlenul szukseges modul)
"Azokat rakom egy RPM-be, amik mindegyik installhoz kellenek. A többit külön. Esetleg, ha lehet csoportosítani a szervereket valami elv alapján, akkor lehet több modult is egy RPM-be pakolni, amiket az adott csoport gépeire mindíg kell telepíteni. (pl. Tomcat-es gépekre a tomcathez szükséges modulokat egybe, stb.)"
Milyen biztonsagi kockazatot latsz egy a szerveren ottlevo, de nem betoltott Apache modul eseten? A konnyebb mendzselhetoseg miatt en annak a hive vagyok, hogy minden modul menjen egy nagy RPMbe, hiszen - szerintem - kockazatot nem jelent egy letezo, de be nem toltott modul.
- A hozzászóláshoz be kell jelentkezni
"Milyen biztonsagi kockazatot latsz egy a szerveren ottlevo, de nem betoltott Apache modul eseten?"
Semmit. Ha a konfigurálás rendben van, és még véletlenül sem kerül nem használt és emiatt rosszul konfigurált modul betöltésre. Ha nagyon paranoidak vagyunk, az jelenthet némi extra kockázati tényezőt, ha egy nem használt modul okozta függőség miatt más oprendszer library-k is telepítésre kerülnek.
Pl. a mod_auth_ldap miatt ldap kliens libek is felkerülnek, habár arra semmi szükség nem lenne.
De nyilván az ilyen dolgok megfelelő üzemeltetési gyakorlattal (normális patch management) kezelhetők.
Ha felesleges dolgok vannak egy szerveren, az önmagában még nem jelent biztonsági kockázatot, ha a felesleges dolog is megfelelően karban van tartva.
A biztonsági kockázat igazából ott van, hogy ha már túl sok mindenre kell figyelni esetleg lankadhat a figyelem (és a fegyelem).
"Igen, a kerdes az lenne, hogy te pl miket raknal bele statikusan es miket nem?"
Amit fentebb írtam. (core, prefork,http_core,mod_so) A statikusan belefordított modulok prefork esetén annyi pédányban eszik a memóriát ahány apache processz fut. Ha veszett sok apache processzed van, akkor pár megát azzal is spórolsz, ha ami csak lehet, dinamikus.
szerk: Normálisan karbantartott webszervernél viszonylag ritka, hogy egy szervermodulon keresztül jön a törés.
az elcseszett user programok okozzák a bajok 99%-át.
- A hozzászóláshoz be kell jelentkezni
koszi, gyakorlatilag ugyanugy gondolkodunk a dologrol
- A hozzászóláshoz be kell jelentkezni
A biztonsági szempontoknál az is fölvethető, hogy ki, mikor, hogyan fogja ezeket az rpm-eket frissíteni...
A disztro eredeti csomagjainál (jó függőségdefiníciókat föltéve) ez "símán megy", de a szétszabdalás, egyedi rpm-ek esetén már cifrább lehet a helyzet.
- A hozzászóláshoz be kell jelentkezni