Volt: Alapos vizsgálatnak veti alá a Windows kódját a Microsoft ?

De az Apache-ot nem azért szoktuk újraindítani, hogy gyakoroltassuk vele ezt a műveletet, hanem, mert cserélünk valamit alatta (főleg, hogy a javítások miatt újraindításról volt szó a topikban végig). A graceful-lal (ami gyakorlatilag csak a konfig újraolvasását jelenti, pontosabban azt, hogy az új childok már az új konfiggal működnek majd) ebben az esetben nem sokra mész.

Sting: Egy nagy forgalmu szervernel nem "restart"-al kell ujrainditani az apachot, hanem celszeru "graceful"-al, ez par masodperc alatt ujrainditja a webszervert, mert nem kell megvarnia mig az osszes child process befejezi a kiszolgalast.

érzésem szerint elbeszéltek egymás mellett.

naz egyik fél (1-2mp) CSAK az apache restart-ot méri,

míg a másik fél (percek) a TELJES rendszer restart idejét méri, beleértve az RDBMS-t is, ami természetesen jó néhány perc lehet, tekintettel arra, hogy ugyibár a konzisztens állapotot meg kell őrizni, szabályosan lezárni a DB-ket, aztán induláskor pár dolgot be kell tölteni, majd csak azután lehet elindítani az apache-ot.

Summa summarum: mind2 félnek igaza van, csak más ért restart alatt.

Onnantol kezdve, hogy entert nyomok az apachectl restart utan, addig hogy egy bongeszoben megjelenik egy akarmilyen, az adott szerver altal produkalt oldal max 2 sec telik el.



vs.



netchan

Kicsit el vagy tévedve... ez csak minimális esetben van így...

Nameg a webszerver szvsz nem csak az apache. Mi van, ha a DB szerveren kell változtatni valamit? Egy akkora adatbázis, mint az oldalé lehet... még erősebb vason is egy kicsike idő, hogy az adatbáziskezelő betöltse, nameg a leállása se fél pillanat. Szóval nem "kilövöm a mysqld processest a task managerben és 1mp" szintű a dolog, mint sok otthoni gépen Bár ez függ attól is, hogy milyen DB, én meg eddig csak MySQLt és PostgreSQLt használtam, és gondolom a prog.hu-t nem ezek egyike viszi De ettől függetlenül szvsz ez általánoasn mindegyikre igaz...

Sting: az 1 perces rebootot úgy érted, hogy a rendszer a leállítás elkezdésétől kezdve eljut a loginig? Azaz nincs benne a programok betöltődése... ? Ha tévedek, és mindenestől megvan egy perc alatt... akkor elismerésem

Nem igazán értem hogyan jön össze az oldal megjelenése meg az Apache restart...

Meg milyen Apache? Ami az otthoni gépeden fut, és statikus dokumentumokat szolgál ki? Az nálam is leáll 2 mp alatt.

Az apachectl restart nalam is kb 1-2 masodpercig tart. (enter lenyomasatol az oldal megjelenessig a bongeszoben)

Szerintem te még nem sok nagyforgalmú webszervernek lehettél a gazdája... Az Apache leállása 10mp-től indul és akár percekig (!) is eltarthat ha eléggé aktív szerveren használja az ember. Még FreeBSD-n is.

Egyébként meg a mostani szerver valóban gyors, mert <1 perc alatt rebootol.

Hát nem tudom egy apachtrl restart kb 1-2 mp alatt fut le (ha a konfigot nem rontom el). Gyors géped van

A témát átneveztem, mert az eredeti hírhez kb. 0 köze van. Hagyjunk annak is egy témát!

Huh bocs ez nem ide ment...

Haho!

En nem is ertem miert nem a Delphi-t valasztottak erre a celra :)

Jesszusom!

Akkor ezexerint csak en vagyok olyan mazlista hogy akkor futok bele az oldalba amikor epp elerhetetlen?
Iden kb ketszer is ha nem haromszor.

Kb. ugyanannyi. Halál komolyan mondom.

Igy igaz, de amig egy windows rebootol, hanyszor lehet ujrainditani egy webszervert? Vagyis mennyi ido esik ki olyankor?



En ezt irtam: "Allitolag a Windows a legbiztonsagosabb es a legjobb oprendszer."

Az uptime a legjobb oprendszerre vonatkozott. Latod mennyit szamit egy kis felreertelmezes? Na most amig en a forumba irtam neked egy picit felreertheto mondatot, addig te az egesz olvaso sereget szedited a cikkekben levo apro hibakkal. Na most melyik a nagyobb hiba?

Addig sincs amíg az ember csak a webszervert állítja le. Csak míg előbbi jelentkezik az uptime-ban, addig utóbbi nem. Ezért mondtam, hogy ez a mérőszám semmit nem ér, sem a rendelkezésre állás, sem a biztonság szempontjából (amivel te eredetileg dilletáns módon összefüggésbe hoztad, és amiről most gőzerővel tereled el a szót).

Az új rendszeren egyébként az oldal rendelkezésre állása a megnövekedett forgalom ellenére sem rosszabb, mint a régin. Bár ebben legkevésbé az OS-nek volt szerepe korábban és most is.

Sting! Ez egy szolgaltatas. Azon dolgoztok, hogy minel jobb legyen. Ezek a 3rd party dolgok masoknal is megvannak, ha ott ki tudjak kuszobolni akkor itt miert nem megy?

1. nincs aram? UPS!
2. net eleres nem jo? Valtani kell szolgaltatot.
3. hibas a vas? ki kell cserelni.

Sting, most oszinten! Nem arrol van inkabb szo, hogy minden egyes secutity update-nel ujra kell inditani a gepet? Marpedig amig bootol a gep, addig all a szolgaltatas, tehat nincs rendelkezesre allas. En csak erre probaltam reflektalni az uptime-al.

Az volt az a vas, amiről már szóltam... de tökmindegy az uptime, mert most 33 napos például azon a gépen, mert egy emelettel feljebb vitték a szerverhostingnál. Előtte kb. 90 nap volt, amikor a rendes éves karbantartás miatt állt egy kicsit. Azelőtt meg kb. 60 napot ment, mert egy kernel upgrade miatt újra kell indítani... :)

Igen, volt 150 nap is. Lehetne több is, meg kevesebb is... nem ettől biztonságos... az uptime csak a megbízhatóság, rendelkezésreállás és robosztusság egyik mérőszáma... :)

Ejnye! Mar el is felejtetted melyik cikkeiden keletkeztek hatalmas flame-ek?



Miert nem te? O a szovivod?
Najo, nem szemelyeskedunk, ez nem az a hely.

Szerintem nem csak lehetett, volna hanem kellene is. Ez az ujsagiroi szakma resze, hogy egyenes tajekoztatasban legyen resze az embereknek, nem?



Es miert is nem? Ha 100-at nem is, de 1 is eppen eleg! Mitol vagy olyan biztos benne, hogy a kis harakiri japanban nem talalt benne egy bugot es most eppen nem arra hasznalja, hogy megkopassza kedvenc bankjat?


Hat igen, feltetelezni is kell! En pl. biztosra veszem, hogy MINDEN oprendszerben van jopar hiba amit elobb-utobb fel is fedeznek. De most ne a masik kertjebe mutogassunk a kutyagumira mikor a sajatunkban egy halommal all.



Mitol volt az kirohanas? Csak mert erdemben nem tudtal ra reagalni? Ezzel, hogy kirohanasnak titulaljuk le is van tudva. Vegulis ez is egyfajta megoldas...

Akkor másikon. De a vason kívül is van (vagy nincs) áramellátás (gondolhatod, nem véletlenül írom most ide), meg a Windows-on kívül is lehetnek 3rd party komponensek a gépen, amik szintén befolyásolhatják a dolgot. Ezen kívül tucatszám tudok neked mutatni pl. linuxos szervereket, amik még ilyen uptime-ot sem érnek el.

A különbség kettőnk között, hogy én ezekből a semmitmondó adatokból nem akarok hamis következtetéseket levonni, és hamis hipotéziseket megtámogatni.

Korrekt! De nem olvastam a hirek kozott, hogy 'gondunk van a hardverrel, elnezest a szolgaltatas akadozasaert'. Volt egy jo idoszaka is a prog.hu-nak amikor meg FreeBSD-n futott. Akkor 150 napig is el tudtak menni. Vagy akkor masik vason futott?

Szerinted így van? Vagy ki szerint?


Ahhoz, hogy megértsd, először odáig kellene eljutnod, hogy rájöjj: az uptime-nak semmi köze a biztonsághoz. De még a rendelkezésre álláshoz sem nagyon.

Az érdemi választ egyébként a kérdésre franko már megadta.

Annyiban igazad van, hogy - ha a szavagokon akarunk lovagolni, akkor - a "felfedezett" mellé az "és közismertté vált"-ot is oda lehetett volna írni.

A másik oldalon semmi okunk nincs feltételezni, hogy még 100 másik sebezhetőséget is felfedeztek. Vagy ha igen, akkor ezt minden más rendszer esetében is feltételezhetjük (ti. hogy most is van 100 foltozatlan, de a rosszfiúk által már aktívan kihasznált sebezhetőség a Linux-ban, FreeBSD-ben, MacOS-ben is).

Tehát alapvetően nem látom relevánsnak a megállapításod, a 10:06-os kirohanásod után pedig kifejezetten hiteltelen kritika.

Csak egy kicsit beleszólok: az uptime a hardvertől is függ... :)

Mondjuk átéltem már olyan időszakot, hogy (feltehetőleg) alaplapi vezérlő-hibás gép igen stabilan működött, csak nagyobb méretű programokat nem tudtam fordítani hiba nélkül... illetve hajigálta a processzeket különféle SIGxx számokkal, de ehhez szerencse is kell, hogy ne a kernel futásakor tévedjen az alaplap. Aztán cserével megoldódott (sikerült a nem használt IDE vezérlőt el...ni, így garanciában visszavették, a ,,nem stabil'' hibaleírásra nem biztos, hogy cserélték volna... :)

Itt a lenyeg...
Allitolag a Windows a legbiztonsagosabb es a legjobb oprendszer. Megsem ertem, hogy a prog.hu miert nem tud elerni 60 napnal nagyobb uptime-ot.

Állítólag a most kikerült kód a trusted computing meghirdetése előtti állapotot tartalmazza. Arról van szó, hogy emiatt most mégegyszer átvizsgálják a kódot, vagyis (legalább) egyszer már átnézték ezelőtt is. Én nem értek a kernelprogramozáshoz, nem is láttam a kódot, de imho nem hiszem hogy túl rossz minőségű lenne. Zila

Nem kesett el ezzel 1 picit a M$? Bezzeg ha nem kerult volna ki a kod a netre, akkor at se nezne! Ennyit a trusted computing-rol.
Tovabba:


Attol, hogy valaki kozkinccse tette az altala felfedezett bugot, nem jelenti azt, hogy O AZ EGYETLEN aki talalt benne!
Eszmeletlen, hogy mennyire kepesek manipulalni egyesek az embereket apobb csusztatasokkal! Sracok! Attol, hogy lenyugtatjatok a nepet, nem fognak megszunni a hibak! Ideje lenne a PR szoveg szerkeszto helyett a kod szerkesztot kezbevenni!