Hi !
Van (lessz) egy apache2 szerver mysqlel, phpmyadminnal.
Ez 1 vserveren fog futni.
A mysql hogy fut biztonságossabban?
1.) A vserver hoston és csak a socketet adom az apacsos vservernek ?
2.) Csinálok neki 1 külön vservert a belső virtuális hálóra, és kiteszem annak az ip-jére, ahonnan eléri a másik szerver ?
3.) Ugyanazon fut mint az apacs ?
4.) Tökmind1
Thx :)
- 1319 megtekintés
Hozzászólások
4
- A hozzászóláshoz be kell jelentkezni
4
- A hozzászóláshoz be kell jelentkezni
socketes elérés mintha gyorsabb lenne, mint a tcp kapcsolaton keresztuli kommunikacio.
amugy 4.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
4 csak rendesen meg kell csinálni és nem összehányni
Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22-rc7-wifi0 - 2.6.22-rc7 kernel madwifivel itt
- A hozzászóláshoz be kell jelentkezni
Az Apacheot rakd be jailbe.
- A hozzászóláshoz be kell jelentkezni
En az 1-re szavazok.
ASK Me No Questions, I'll Tell You No Lies
- A hozzászóláshoz be kell jelentkezni
Szerintem meg a zapache-ot vagy mod_security-val vagy máshogy chrootold. A mysql pedig gyárilag tud chrootot már.
Ha localhoston vannak, akkor pedig tcp-vel is tudnak jól kommunikálni.
- A hozzászóláshoz be kell jelentkezni
update: félrever a szívem és még nem volt meg a kvm, töröltem a bejegyzésem :)
- A hozzászóláshoz be kell jelentkezni
A libmysqlclient, ha localhoston van es socket eleres lehetseges, akkor nemigen tudod tcp-re kenyszeriteni. Valamiert, ha erzi, h azonos hoston fut, akkor socketet kenyszeriti. Nemtom ez hol dokumentalt behavior es hogy hogy lehet megkerulni.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
localhost vs. 127.0.0.1 :)
- A hozzászóláshoz be kell jelentkezni
?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
localhost -> socket
127.0.0.1 -> tcp
- A hozzászóláshoz be kell jelentkezni
Ugy-ugy...
ASK Me No Questions, I'll Tell You No Lies
- A hozzászóláshoz be kell jelentkezni
"Hol fusson a Mysql ?"
Ne forró zsírban! :D
Sztem 4.
ill nyóc.
----------------------------------------------------------------
- A hozzászóláshoz be kell jelentkezni
Ugyan nem annyira biztonsagi, mint megbizhatosagi kerdes, de szerintem lenyeges, hogy ne kozos memoriaban fussanak.
Mind a kettonek van hajlama forkolni mint egy okor. Aztan elfogyasztjak egymas elol a memoriat.
Ez persze nagy terhelesnel esik meg. Csak hat "az interneten" nem annyira te szabalyozod mennyire terhelik meg a szerveredet.
Kedvenc jelenetem:
1. Nincs epeszu MaxClients az apacheon.
2. bejon majom es szetbombazza az indian agyat 2000req/mp-cel egy jo kis dinamikus oldalra.
3. Apache forkol, SQL forkol, fogy a memoria,
4. elerik a pontot amikor elkezdunk swappelni
5. mysql elkezd torlodni mert allandoan diszkrol kell neki minden olvasnia. Meg az aktiv memoriajat is :)
6. apache-ok elkezdenek torlodni, mert az SQL-re varnak.
S igen lattam mar ilyet. A sajat szervereimen :)
S ez meg nem is jatszik a diszk I/O-val. Ott is tudnak versenyezni.
Jon be a sok insert/update az SQL-be mikozben az apache meg error/access logol. Ez is tud okosakat eloallitani.
Biztonsagi szempontbol gondold vegig...
Az apache-ban fut egy alkalmazas ami hozzafer az adatbazishoz? Innentol mennyire szamit, hol van az az SQL peldany? Ugyis ott van a webszerveren az osszes szukseges hozzaferesi parameter. De meg erre sem feltetlenul van szuksege, csak egy jo kis bugos PHP scriptre a szerveren.
- A hozzászóláshoz be kell jelentkezni
Jol hangzik, de mennyivel jobb az, hogy
A) 1 gep (1G RAM, 1GHz) spache + 1 gep (1G RAM, 1GHz) mysql
mint
B) 1 gep (2G RAM, 2GHz) apache+mysql
Mert ha A-nal a mysql elkezd nem (ill. lassan) valaszolni, az apache processzek
ugyanugy varnak sql-re. Imho a B) is jarhato, ha korrekt eroforras limiteket
allitasz be: max. ennyi meg ennyi kerest engedunk a apache/mysql fele, a tobbit
meg eldobjuk, vagy queue-ba tesszuk.
ASK Me No Questions, I'll Tell You No Lies
- A hozzászóláshoz be kell jelentkezni
Arról nem beszélve, hogy így a Disk I/O konfliktus elkerülődik.
Mondjuk én a lehetőségekhez mérten mindenképp külön tenném, mert így sem memóriában sem a lemezen nem kell osztozkodniuk, így effektív kissebb a konfliktus esélye.
Persze a weboldal SQL szkriptjeit sosem árt leellenőrizni, vannak Apach stress testek dögivel.
- A hozzászóláshoz be kell jelentkezni
Arrol nem is beszelve, hogy ma egyre nagyobb divat a virtualizacio, ahol van egy nagy teljesitmenyu vasad, es azon hozol letre virtualis gepeket (amelyek valojaban ugyanazt a memoriat - meg a tobbi eroforrast - eszik, ok ennel komplexebb azert a dolog).
ASK Me No Questions, I'll Tell You No Lies
- A hozzászóláshoz be kell jelentkezni
Igen, mondjuk félreérthető voltam, természetesen a külön vas alatt fizikai megjelenésében is két külön vasat értettem (na ezért nem kedvelem egy cseppet a virtualizációt... mi a francnak magyarázkodok? :) ).
- A hozzászóláshoz be kell jelentkezni
Nem kell ezt tulbonyolitani - elegendo egyetlen query ami lockol esetleg meretes IO muveletet vegez es mar torlodott is a sor kiszolgalasa.
A dolog pikanteriaja, hogy a mysql-ben nincs memoria limitacio - szoval szepen fogyaszthatja, ami van.
- A hozzászóláshoz be kell jelentkezni
8
- A hozzászóláshoz be kell jelentkezni
0
- A hozzászóláshoz be kell jelentkezni
3.) lett belőle az 1szerűség kedvéért :)
- A hozzászóláshoz be kell jelentkezni
Szerk.: ja, latom, mar eldolt.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni