Szakmai kategória > Szoftverek
Galaxy RSS 64 bit alatt?
L. Pásztor:
Altalaban a port forward-dal szokott baj lenni.
Valamit csesznek a rendszeren, uj eszkoz, uj szoft aminek egy uj port kell .... rendszerint a routert kell csesztetni. Normal korulmenyek kozt nyitva van 5-10-20 port ennek-annak. Soxor elfelejtik mi- miert van nyitva, aztan valaki fogja es bezarja --- mert hogy mi a francnak van az nyitva, mert majd jol besetsl rajta a sok virus.
Bezar egy portot es onnantol sok kezelo elkezd csipogni ...
Vagy szandekosan alatesz a rendszernek .... volt mar ilyen is.
Illetve majdnem elfelejtettem : vannak (allitolag - csak hallottam) olyan vedelmi rendszerek szervereken ( nem vagyok nagy majer benne) amelyek egy- egy szoft frissiteskor a szoft configja default allapotba all vissza. Ekkor kezzel kell megint cseszni ezt-azt, h megint minden menjen. Na ilyenkor is kimaradhat valami, ami megakasztja a rendszert.
előzmény: mot #31
eXtra:
Ilyesmi nálam akkor szokott előfordulni, ha a helyi rencergéza csak a belső hálózatot kezeli (esetleg többen is vannak és nem rendszerben dolgoznak), de a tűzfalat és szervereket egy külsős cégre bízták... Persze ettől még lehet, hogy léteznek rosszindulatú, gonosz informatikusok, akik direkt ártani akarnak nekünk, de szerencsére én még nem találkoztam ilyennel és velem sose genyázott egyik se. :)
Amúgy nekem is volt olyan ügyem, amikor a helyi rencergéza széttárta a karját, hogy mindent átnézett, de nem tudja mi tiltja a riasztó IP-jét. Nincs IP ütközés, ezért valószínűleg a tűzfal tiltotta ki, vagy a fax tudja mi történt - volt a válasz... :D A hosszas keresgélés vége az lett, hogy a riasztót áttettem másik IP-re és azóta nincs vele gond. Illetve 1-2 évente egyszer ugyanezt eljátsszák, de akkor már percek alatt megoldjuk az ügyet. előzmény: mot #31
mot:
Az a gáz, hogy ez itt most kétélű dolog. A rendszerek távfelügyeletét helyre tudom állítani, de a problémát nem a riasztók okozták. Ha most simán átállítom a riasztókat és minden flottul megy tovább, akkor a hálózat-üzemeltetés azt mondja, hogy "lám-lám, mi megmondtuk, nincs itt semmi hiba, a ti rendszereitekben (érts: riasztók) volt a probléma, mert ti megoldottátok". Tipikusan az a helyzet, hogy a probléma meg lett ugyan oldva, de nem azzal, hogy az eredeti probléma lett megoldva. Ezért kérdezem a hálózatokhoz értő kollégákat, hogy mit kellett a hálózaton (illetve az aktív hálózati eszközökön, vagy akár a fogadó PC-n) b@szni ahhoz, hogy ez a probléma előforduljon.előzmény: L. Pásztor #30
L. Pásztor:
A TCP és az UDP más szálon futnak, ha pl. az egyik portját el-piszkálták, akkor a másikon még bemegy.
Illetve lehet több port is nyitva, nem csak több socket, így a júzerek (a riasztók) egy része itt, más része pl. más porton is bemehet. Ha valamelyiket kilövik, akkor az arra cimzett kliensek kiesnek.
Hozzáértő, de az élet folyásával elégedetlen rendszergazdák, unalmas délelőttökön, szendviccsel a kezükben youtube-ozás közben szoktak a jól működő rendszerekre halálos csapást mérni ... vagy kicseszésből ... mert láttunk már olyat is.előzmény: mot #29
mot:
Több Galaxy központ informatikai hálózaton, IP modulon keresztül kommunikál az Alarm Monitor (ingyenes Honeywell távfelügyeleti progi) programmal. Egyszercsak valami történt az informatikai hálózattal - nem tudjuk mi - és jópár központ már nem tudott kommunikálni a távfelügyeleti progival. RSS-el meghívva a központot és letöltve az eseménymemót gyönyörűen látszik, hogy a kp. akart kommunikálni, de minden esemény után ott a kom. hiba. Informatikai hálózatot üzemeltető persze semmi módosításról, hálózati korlátozásról nem tud. Megnéztem egy-egy kommunikáló és nem kommunikáló rendszer Ethernet beállításait és láss csodát, ahol a protokoll TCP volt, azok nem kommunikáltak, amik UDP beállítással voltak, azok kommunikáltak. TCP-ről UDP-re átállítva azonnal helyreállt a kommunikáció. Kérdés, hogy mi a pék f@szát állíthattak át az informatikai hálózaton? Ötletek?
Navigáció
[#] Következő oldal
Teljes verzió megtekintése