Volt: Alapos vizsgálatnak veti alá a Windows kódját a Microsoft ?
2004-02-20T09:35:47+01:00
2004-02-22T12:20:35+01:00
2022-07-19T05:37:40+02:00
  • 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.
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • é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.
    Mutasd a teljes hozzászólást!
  • Nem igazán értem hogyan jön össze az oldal megjelenése meg az Apache restart...


    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.

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


    vs.

    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.


    netchan
    Mutasd a teljes hozzászólást!
  • 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
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • Az apachectl restart nalam is kb 1-2 masodpercig tart. (enter lenyomasatol az oldal megjelenessig a bongeszoben)
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • Hát nem tudom egy apachtrl restart kb 1-2 mp alatt fut le (ha a konfigot nem rontom el). Gyors géped van
    Mutasd a teljes hozzászólást!
  • A témát átneveztem, mert az eredeti hírhez kb. 0 köze van. Hagyjunk annak is egy témát!
    Mutasd a teljes hozzászólást!
  • Huh bocs ez nem ide ment...
    Mutasd a teljes hozzászólást!
  • Haho!

    En nem is ertem miert nem a Delphi-t valasztottak erre a celra :)
    Mutasd a teljes hozzászólást!
  • Kb. ugyanannyi. Halál komolyan mondom.


    Jesszusom!
    Mutasd a teljes hozzászólást!
  • Az új rendszeren egyébként az oldal rendelkezésre állása a megnövekedett forgalom ellenére sem rosszabb


    Akkor ezexerint csak en vagyok olyan mazlista hogy akkor futok bele az oldalba amikor epp elerhetetlen?
    Iden kb ketszer is ha nem haromszor.
    Mutasd a teljes hozzászólást!
  • Igy igaz, de amig egy windows rebootol, hanyszor lehet ujrainditani egy webszervert? Vagyis mennyi ido esik ki olyankor?

    Kb. ugyanannyi. Halál komolyan mondom.
    Mutasd a teljes hozzászólást!
  • Addig sincs amíg az ember csak a webszervert állítja le.


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

    amivel te eredetileg dilletáns módon összefüggésbe hoztad, és amiről most gőzerővel tereled el a szót


    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?
    Mutasd a teljes hozzászólást!
  • Marpedig amig bootol a gep, addig all a szolgaltatas, tehat nincs rendelkezesre allas.

    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.
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • 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... :)
    Mutasd a teljes hozzászólást!
  • Szerinted így van? Vagy ki szerint?


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

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


    Miert nem te? O a szovivod?
    Najo, nem szemelyeskedunk, ez nem az a hely.
    Mutasd a teljes hozzászólást!
  • 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.


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

    A másik oldalon semmi okunk nincs feltételezni, hogy még 100 másik sebezhetőséget is felfedeztek.


    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?

    akkor ezt minden más rendszer esetében is feltételezhetjük

    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.

    10:06-os kirohanásod


    Mitol volt az kirohanas? Csak mert erdemben nem tudtal ra reagalni? Ezzel, hogy kirohanasnak titulaljuk le is van tudva. Vegulis ez is egyfajta megoldas...
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • az uptime a hardvertől is függ...


    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?
    Mutasd a teljes hozzászólást!
  • Allitolag a Windows a legbiztonsagosabb es a legjobb oprendszer.

    Szerinted így van? Vagy ki szerint?

    Megsem ertem, hogy a prog.hu miert nem tud elerni 60 napnal nagyobb uptime-ot.

    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.
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • 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... :)
    Mutasd a teljes hozzászólást!
  • Állítólag


    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.
    Mutasd a teljes hozzászólást!
  • Á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
    Mutasd a teljes hozzászólást!
  • 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:
    felfedezett első és eddig egyetlen sebezhetőség


    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!
    Mutasd a teljes hozzászólást!
abcd