Miben írták a Prog.Hu-t?
2004-02-16T14:36:29+01:00
2004-02-20T16:37:34+01:00
2022-07-27T14:12:57+02:00
  • dBase
    Mutasd a teljes hozzászólást!
  • MySQL? Hmmm... Ami azt illeti én azt használok, de csak mert a free szervereken általában az fut. A magamfajta ingyenélő suttyóknak ez a sorsa.
    Mutasd a teljes hozzászólást!
  • MSSQL mert "ismerlek", mySQL említése is nevetséges lenne, Oracle meg drágán méri azt amit megkapsz MSSQL-ben. Ami meg a teljesítményt ílleti ezen felhasználási helyen szerintem közel azonos. De mind1, úgysem mondod meg, mert keresnek rá gonosz manók exploitot. Lényeg, hogy az is elég, ha megírod, hogy mi nem.
    Legalább írd ide, hogy nem opensource, hogy megnyugodjanak/fellázadjanak egyesek !
    Mutasd a teljes hozzászólást!
  • Én az Access-re tippelek...

    MySQL, Oracle fel sem merül?
    Mutasd a teljes hozzászólást!
  • Igen. Tényleg jó.
    Mutasd a teljes hozzászólást!
  • A Microsoft SQL Servere tényleg olyan jó?
    Mutasd a teljes hozzászólást!
  • 1. tipp: MSSQL
    2. tipp: PostgreSQL
    3. tipp: Acces
    Mutasd a teljes hozzászólást!
  • Jó ha ezt megbeszéltétek, akkor feldobom a témában azt a kérdést, amiről még nem folytattunk vérremenő vitát:
    Mi van az adatbázis kiszolgálójával?
    Tessék várom a lehetséges válaszokat
    Mutasd a teljes hozzászólást!
  • Tehát jól beizgatod a népet, hogy open source szoftverkomponens beborította az árkoba a Windowst

    Idáig kb. 3x írtam le, hogy ez ügyben mi a helyzet, de a jelek szerint még mindig nem sikerült felfogni. Ha nem haragszol, ezen a vonalon feladom a további próbálkozásokat.

    aztán azt mondod... hogy nem mondhatod meg. Ez kissé hiteltelenné teszi a magyarázatot, engedd meg, hogy ne higyjem el.

    Azt hiszel amit akarsz. Sőt, te csak azt hiszed el, amit akarsz. Mindenesetre a szerver biztonságát nem fogom a lelki békéd miatt kockáztatani.
    Mutasd a teljes hozzászólást!
  • Sokmindent. Megfelelő utasításokkal megfelelő célt elérni... függ a túlterhelés okától is. Például visszevenni a fogadható kapcsolatok számát, stb. 5-6 percen belül rendezni lehet a problémát (volt rá példa később is). Csak ez telefonon 20-30 perc is lehet akár.

    Tehát jól beizgatod a népet, hogy open source szoftverkomponens beborította az árkoba a Windowst, aztán azt mondod... hogy nem mondhatod meg. Ez kissé hiteltelenné teszi a magyarázatot, engedd meg, hogy ne higyjem el.
    Mutasd a teljes hozzászólást!
  • Viszont a program és verziója pontos ismerete elegendő az összes potenciális lyuk kihasználására. És elegendő indok esetén ki is szokták használni.

    Azt értsd már meg, hogy az, hogy egyetlen egy komponens típusát, talán ki lehet silabizálni, nem alap arra, hogy az összes többi komponenst is önként felfedje a szerver tulajdonosa. Te most a jelek szerint ezt akarod bizonygatni, hogy ti. nincs értelme titkolni a rendszer 20-30 különböző komponensének a pontos megjelölését, mert az egyik a típusát úgy-ahogy (típust talán, verziót nem feltétlenül) meg lehet állapítani.

    tudtam jelen lenni és telefonon távolról irányítani egy megfelelő szinten hozzá nem értőt

    Nem tudom mit tudott volna belátható időn belül csinálni egy megfelelő szinten hozzá értő személy azon a gépen, ahol fél-egy perces késleltetéssel echozott az ssh konzol, mert annyira túlterhelt volt szerencsétlen masina.

    Melyik az a kernel módú opensource driver, amit Te használsz Windows alatt?

    ->Előzmények - Miben írták a Prog.Hu-t? - Társalgó - Prog.Hu
    Mutasd a teljes hozzászólást!
  • Az 5.x-es FreeBSD-t nem javasolják éles környezetben való használatra, sokak szerint a 4.9 sokkal gyorsabb.

    A baj, hogy a 5.x előtti FreeBSD-k nem támogatták a gépben használt RAID vezérlőt, ráadásul - ha jól emlékszem - a HT-támogatás körül is volt valami probléma.
    Mutasd a teljes hozzászólást!
  • Hát... ha egy program letöltése és elindítása csökkent valamit a veszélyen, akkor legyen igazad... :)

    Viszont a program és verziója pontos ismerete elegendő az összes potenciális lyuk kihasználására. És elegendő indok esetén ki is szokták használni.

    Persze... volt túlterhelés... de ebből adódó (szükségszerű) újraindításra nem emlékszem. Egy alkalommal történt ilyen, amikor nem tudtam jelen lenni (hehh... nászúton ezért zavarni egy rendszergazdát... :) és telefonon távolról irányítani egy megfelelő szinten hozzá nem értőt: ez volt a leggyorsabb és legegyszerűbb javítási mód.

    Melyik az a kernel módú opensource driver, amit Te használsz Windows alatt? (vö:
    másrészt pont egy nyílt forrású komponens okozta őket.
    :)))
    Mutasd a teljes hozzászólást!
  • Nah... akkor jól gondoltam, hogy talán nem volt jól beállítva a BSD... :)
    Mutasd a teljes hozzászólást!
  • Az 5.x-es FreeBSD-t nem javasolják éles környezetben való használatra, sokak szerint a 4.9 sokkal gyorsabb.
    New Technology Release: 5.2
    Production Release: 4.9
    Mutasd a teljes hozzászólást!
  • Nem kell bejutni a gépre, hogy megismerje valaki, mit is futtat... apróbb működési jellegzetességekből lehet rájönni arra, hogy például milyen típusú és verziószámú SMTP fut a gépen, akkor is, ha az maszkolja az üdvözlő szöveget. És erre nagyon kiforrott és jól működő programok vannak... :)

    Ez így van, de ettől még ez is csökkenti a kevésbé képzetlen, alapos, stb. próbálkozások sikerét. A másik dolog, hogy ez is csak egyetlen komponens. Azaz, attól, hogy erről szerez infót, a többi potenciális bejutási pontról még mindig nem lesz infója a támadónak.

    Milyen mélyen épül bele az oprendszerbe a free komponens Windows alatt annyira, hogy annak működését veszélyezteti?

    Elég ha van benne egy kernel módú driver. De DoS-hoz még ez sem kell. Ugye te is tudnál arról mesélni, amikor egy bizonyos FreeBSD-s gép egy halál közönséges alkalmazástól bénult meg - csak azért, mert az felfalta gyakorlatilag az egész memóriát?

    érdekelne az a free komponens, amely például jail-ben annyira megfekteti a rendszert, hogy azt újra kelljen indítani... :/

    Akármelyik kernel modulban van egy bug, az az egész rendszert hazavághatja. Windows alatt sem az alkalmazások (=kizárólag user módú komponensekből álló programok) okoznak rendszerleállást.
    Mutasd a teljes hozzászólást!
  • Hehh... akkor az összehasonlítás nem él, mert a FreeBSD egyrészt 4.6-os, illetve a két szerver hardverre nem ugyanaz.

    Olvasd el még egyszer mit írtam. Én nem arról a szerverről beszéltem, amelyikről te, hanem arról, amelyiken FreeBSD és Win is volt, mielőtt Win maradt volna rajta.
    Mutasd a teljes hozzászólást!
  • Hehh... akkor az összehasonlítás nem él, mert a FreeBSD egyrészt 4.6-os, illetve a két szerver hardverre nem ugyanaz.
    Mutasd a teljes hozzászólást!
  • Szakmailag megalapozatlan? Hehh...

    Nem kell bejutni a gépre, hogy megismerje valaki, mit is futtat... apróbb működési jellegzetességekből lehet rájönni arra, hogy például milyen típusú és verziószámú SMTP fut a gépen, akkor is, ha az maszkolja az üdvözlő szöveget. És erre nagyon kiforrott és jól működő programok vannak... :)

    Free komponens:
    Milyen mélyen épül bele az oprendszerbe a free komponens Windows alatt annyira, hogy annak működését veszélyezteti? Szakmai hozzáértés megint... érdekelne az a free komponens, amely például jail-ben annyira megfekteti a rendszert, hogy azt újra kelljen indítani... :/

    Értsem ez alatt, hogy egy egyszerű (akár admin jogokkal futó) program képes megfektetni a rendszert? Hol itt a legendás biztonság? :)

    Jaigen: A ,,működési zavar'' után valahogy újraindult az oprendszer is.
    Mutasd a teljes hozzászólást!
  • IRONIA:
    nos, igen en is feltetlezem, hogy korabban nem a legjobb beallitasokkal futott a dolog, csupan azert, hogy most ilyen jo eredmenyekrol lehessen beszamolni

    Te nem tudsz valamit: a régi gépnek franko volt a rendszergazdája.
    Mutasd a teljes hozzászólást!
  • Sajnos szakmailag eléggé megalapozatlan amiket írsz.

    Egyrészt ugyanis először be kell jutni a rendszerre. Amikor már bent van valaki, akkor valóban csak egy könyvtárlistázás, hogy megállapítsa mi van a gépen - de ekkor már nagyjából mindegy is, hogy mit talál.

    Ha viszont valaki nem tudja mit talál bent egy gépen, akkor a vakon próbálgatás miatt sokkal nagyobb valószínűséggel fut bele az előre elhelyezett csapdákba, mint ha először jó exploittal próbálkozna. Ez pedig erősen csökkenti az esélyét a sikeres bejutásnak, mert a mindenkori rendszergazdának van ideje elhárítani a támadást.

    A másik, hogy a "free szoftverkomponensek hibája" is simán indokolhat újraindítást, bármilyen OS alatt. Ez ugyanis nem nyílt v. zárt forrás kérdése, hanem annak, hogy milyen mélyen és hova épül bele a rendszer működésébe.

    Ha egyébként alaposan olvastál volna, akkor feltűnt volna, hogy én nem azt írtam, hogy az uptime-mot befolyásolták ezek a komponensek, hanem, hogy ezek voltak a működési zavarok okozói.
    Mutasd a teljes hozzászólást!
  • IRONIA:
    nos, igen en is feltetlezem, hogy korabban nem a legjobb beallitasokkal futott a dolog, csupan azert, hogy most ilyen jo eredmenyekrol lehessen beszamolni
    Mutasd a teljes hozzászólást!
  • A free (szoftver)komponensek hibája nem indokol újraindítást... :)

    A Windows (kop-kop) kiválóan teljesít alatta, és ugyanazon a hardveren mérhetően jobb teljesítményt nyújtott, mint a FreeBSD 5.x-es sorozata.

    Hmmm... a részletekre kiváncsi lennék... Sokféle beállítás lehetséges mindekét rendszeren, amelytől a teljesítmény 10 és 100% között bármilyen értéket felvehet... :)
    Mutasd a teljes hozzászólást!
  • Hááát... aki be tud törni, annak adtál volna 30 másodperc előnyt. Egyszerűen nem azon múlik egy oldal/szerver feltörése, hogy tudja-e a támadó, mi is van a gépen. Olyan ,,kellenes'' eszközök vannak erre, hogy egy programfuttatásnyi időt nyertél ezzel a titkolózással.

    Másrészt ha titkolózol, akkor egyetleg pont ezzel kelted fel valakinek az érdeklődését: kíváncsi lesz és megnézi, mi is ez a nagy titkolózás... :)

    Szóval felesleges titkolni, aki akarja, úgy is megnézi... nincs olyan sok Windows verzió, másrészt nincs olyan sok elterjedt webszerver és adatbázisszerver, ami között választani kell... :)
    Mutasd a teljes hozzászólást!
  • Rendszeresek lettek a leállások

    Lehet, hogy nem ugyanazt az oldalt látogatjuk?

    Az oldallal egyébként a közelmúltban rövid ideig voltak átmeneti zavarok, de ezek egyrészt már jóval az átállást követően történtek, másrészt pont egy nyílt forrású komponens okozta őket. A Windows (kop-kop) kiválóan teljesít alatta, és ugyanazon a hardveren mérhetően jobb teljesítményt nyújtott, mint a FreeBSD 5.x-es sorozata.
    Mutasd a teljes hozzászólást!
  • security through obscurity? a microsoft.com felépítése is publikus, nem ettől lesz biztonságos a rendszer.

    A dolog úgy igaz, hogy ettől nem lesz biztonságos. Ettől függetlenül nagy taktikai előny egy hackernek, ha pontosan tudja mit találhat a célgépen.
    Mutasd a teljes hozzászólást!
  • a rosszindulatúaknak viszont értékes információk


    security through obscurity? a microsoft.com felépítése is publikus, nem ettől lesz biztonságos a rendszer.

    d5
    Mutasd a teljes hozzászólást!
  • egyébként nem kell elájulni a php teljesítményétől, bár nem is rossz, de azért itt nincs olyan forgalom. A Prohardver is php, ott jóval nagyobb a forgalom, és ott már eléggé döglödőtt is a rendszer egy pc kategóriában viszonylag erős szerver mellett is.
    Mutasd a teljes hozzászólást!
  • egyébként a prog.hu régen php volt és bsd-n futott. Sting átrakta windowsra, de nem hiszem, hogy átírta php-ból másra. Rendszeresek lettek a leállások, de nem lett több bug benne, ha pedig átírta volna, akkor óhatatlanul lettek volna új bugok.
    Mutasd a teljes hozzászólást!
  • jsp szerintem is gyors, pontosan ezt írtam, sőt nemcsak valamiféle kategórián belül... Valaki egyszer mérte a konfigurációját, hogy megnézze hogy konfigurálja, és azon a gépen a Tomcat gyorsabban szolgálta ki a hosszú statikus fájlokat mint az Apache. Dinamikus lapoknál hozzáadódik a karakterkódolás ideje, amit statikus részeknél meg lehetne spórolni, de azt szerintem csak szervlettel lehet praktikusan, ennyi.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd