Hozzászólások
-
Bejegyzés
-
Látom, nem nagy az érdeklődés, de annyit közben megtudtam, hogy az RFC szerint az MX rekord megléte nem szükséges. Ha nincs, a levelet az A rekordra kell küldeni. 🙁 Így mx szűrni igazából nem is szabad.Bár ennek lehetne egy bővített változata, hogy a levelet akkor fogadjuk, ha van MX, vagy ha nincs, de az A rekord által megadott IP címen van üzemelő 25-ös port. Erre azonban a levelezők már egyáltalán nicsenek felkészülve, bár a saját queue-mban töttyedő levelek 80% így be sem jutott volna a szerverre ...
Nem teljesen értek egyet a tárhelytakarékossággal, hisz ha van RAID, az nem jelenti azt, hogy csak RAID-nek szabad lennie.Én olyan tárterületet akarok, ahol minden mentve van, így ezzel nem tudnék spórolni, de ha lenne egy data mappám, amit nem akarnék duplikálni, azt valószínűleg kitenném a tömbből.Az rsync-et meg imádom. Jelenleg is ezt használom mindenütt. Meg lsync-et, mert az rsync gyengéje pont az, amit a raid kapásból tud. A menetközbeni erőforráspazarlás.Diskhalál esetén lehet, hogy az rsync ugyanannyi idő alatt másol vissza, mint a RAID, bár a RAID visszamásolási ideje alatt már tudok dolgozni, míg az rsync visszamásolási ideje alatt még nem.De amíg nincs halál, addig az rsync a napi (óránkénti? percenkénti?) szinkronizálásnál sokkal több erőforrást elvisz. És teszi ezt folyamatosan, hisz ha óránként futtatom, akkor is lehet, hogy épp felmásolok valamit, majd megnyugszom, hogy biztonságban, fél óra múlva meg meghal, és nincs mentése. Tudom, kicsi a valószínűsége, de így épp, hogy nem adja a megbízhatóságot. lsync-kel komibálvan meg az isten memóriája sem lenne elég neki, hogy egy teljes fájlrendszert szinkronban tartson, bár az már igazából RAID 1, és akkor meg miért ne lenne RAID 1?Arról nem is szólva, hogy az rsync csak RAID 1-et helyettesítheti, tömbben azonban más RAID-eket is felépíthetnék. (Persze ennek most nincs realitása, egyelőre nincs ennyi lemezem.)Továbbá az sem titkolom, hogy szeretnék kiismerni más technológiákat, mint amiket eddig használtam.
Lehet, hogy ez a partíciós RAID nem olyan gyors, mint a fizikai eszköz alapú, de ha adathiba van, mégis nagyságrendekkel egyszerűbb a helyreállítás. Ha csak LVM és backup, akkor lemezhiba esetén a teljes LVM tartalmát lehet visszatöltögetni. Ez sok-sok terra esetén eléggé güris. Ennél sokkal szimpatikusabb, hogy új particiók be, aztán építse magát újra a háttérben, én meg mindent használhatok tovább, mintha misem történt volna.Attól, hogy nem éles szerver, még lehet komfortos.Az pedig, hogy egy lemez esetén minden partíció megy, a szememben nem hátrány. Egyrészt, mert mindegyiknek megvan a tükre egy másik lemezen, másrészt, mert pont azért van sok partíció, hogy különböző lemezek is RAID-ben lehessenek. Eszköz RAID esetén ezek a partíciók egyben lennének, tehát pont ugyanennyi adat menne semmibe, csak egy partíción. Ez nem nagyobb adatbiztonság. És még a különböző lemezeméretek lehetőségét is elveszíteném.
A google szerint 3% az új meghajtók 1 éven bellüli meghibásodási valószínűsége. Több lemez esetén ez – szerintem – jóval nagyobb kockázat, mint a villám vagy áramingadozás.Ráadásul szeretnék egyetlen nagy fájlrendszert, és nem eszközönként egyet-egyet.Arra is gondoltam, hogy a különböző méretű lemezeimet feldarabolom azonos méretű partíciókra, ezekre teszek RAID 1-et (vagy 5-öt) úgy, hogy az elemei külön meghajtókonk vannak, majd ezeket fűzöm egybe... Ezt nem tudom, meg lehet-e csinálni, vagy a RAID csak teljes meghajtókon képes futni?
Úgy tűnik, többösszetevős a dolog … Amint ezt a választ írom, épp nem lassú az oldal, pedig most is megy az óra …Félek, így nem fogom megtudni, mi fogta meg ... max, ha újra lelassul, majd elkezdem debuggolni ...
Ha le lehetne állítani ezt az órát a jobb felső sarokban, sokat segítene (gyorsítana). Így most i7 procikkal is eléggé akadozik. Haszna túl sok nincs.
Tudomásom szerint csak 3 olyan címtartomány van az IP címtérben, ami nem publikus, de az 1.1.1.1 nincs közötte.Továbbá az 1.1.1.1 szerver tényleg nincs használatban, nem üzemeltet webszervert.Vagyis a böngésző önkényesen jelenít meg tartalmat ezen a címen.Felkerestem ugyanazt az oldalt, ahol ezzel találkoztam, és most nincs benne ilyen url. Vagyis a böngésző valamilyen esetben teszi csak bele ezt az ip címet az url-ekbe.Amikor ezzel az url-lel találkoztam firtefox alatt, megnyitottam a chrome-ot, és oda is bemásoltam az url-t. Meg is jelenítette. De mikor elküldtem valakinek, ő már nem látta.Ezek szerint mégsem böngésző specifikus. Mintha a helyi gépen futna valamilyen olyan url konverzió, amiről nem tudok???Tippem sincs, de egyre jobban zavar, hogy valami olyan történik - ráadásul esetlegesen - a gépemen, amiről nincs tudomásom.
Közben szinte minden kiderült.Volt ugyanis olyan session fájl, ami nem root joggal jött létre.Ebből kiderült, hogy a kérdéses domain aldomain-ja a másik domainnak.Bizonyos böngészők (pl.: IE) azt csinálják, hogy a foo.com domain alatt létrehozott cookie-kat a valami.foo.com domain alatt is elérhetővé teszik. Más böngészők (pl.: Firefox) azonban nem.A kérdéses domain esetén a foo.com domainról induló kérés elinditott egy session-t foo.com user néven (az mpm_itk miatt). Majd ugyanezt a session-t akarta folytatni valami.foo.com domain alatt is - hisz a cookie-ban ott volt a session_id), pedig itt már valami.foo.com néven szerette volma elérni ugyanazt a session-t.Tehát böngésző probléma volt. Egy egyszerű session_name paranccsal megoldottam.Azóta a hiba nem jelentkezett.Egyetlen jelenségre nem ad a fenti magyarázatot, hogy az először talált session fájl hogyan lehetett root jogú?Remélem, ez az én hibám volt, és amikor a session fájlról másolatot csináltam - rootként - akkor lett csak root jogú. (Bár határozottan arra emlékszem, hogy mv paranccsal mozgattam a fájlt, pont emiatt.)Tehát erre nincs ugyan magyarázatom, de azóta nem jelentkezett a hiba. Ha mégsem én hibáztam, akkor elő fog fordulni újra, s akkor tovább nyomozhatok.
legutóbbi hsz