Par szempont, mielott a felhobe (google, office365, ...) vinned a levelezesed

A Waterford technologies keszitett egy irast arrol, mire kell felkeszulni egy ilyen lepes eseten: http://www.waterfordtechnologies.com/blog/file-archiving/storage-manage…

Hozzászólások

Nekem az a nagy problémám, hogy nem lehet össze-clusterezni a felhős és onprem Exchange szervert.

--

Józan cégek soha nem fogják felhőbe vinni a hivatalos levelezősüket Magyarországon. Nem technológiai de üzleti megfontolásokból óriási előny az, hogy szükség esetén nyomtalanul lehet törölni emaileket. :-)
"Felelőtlen" emailes csevegés miatt már maga a Google, Microsoft és sok nagy IT szolgáltató maga is fizetett komoly bírságokat.
Természetesen saját üzemeltetésű felhő szolgáltatás az rendben van.

Az EU elismerését a Microsoft Magyarország egyik legfontosabb ügyfele is üdvözölte. "Tudomásom szerint mi vagyunk az első és egyetlen bank Magyarországon, amely az Office 365 keretében a felhőben oldja meg vállalati levelezését - mondjta Jakab Péter, az MKB Bank bankbiztonsági és IT üzemeltetési ügyvezető igazgatója. - Ez az elismerés visszaigazolta, hogy egy ilyen felhőszolgáltatás jogszerűen és biztonságosan igénybe vehető akár egy pénzintézet részéről is." Jakab hozzátette: a jövőben más banki informatikai rendszereket is a felhőbe költöztethetnek, mivel az Office 365-tel mintegy 20-30 százalékkal alacsonyabbak voltak az üzemeltetési költségek, mint ha helyi szervereken maradt volna a levelezés.

From http://valasz.hu/uzlet/titkaink-a-felhoben-75849

Azt nem tudom pontosan, hogy a "józan cég" definíciója micsoda, de azt gondolom, hogy az MKB Bank ebbe a kategóriába tartozhat.
Ráadásul, ha jól értem, épp előnynek számított a kiválasztásnál, hogy alapszolgáltatásként bármely mailboxon bekapcsolható, hogy az összes valaha ott járt levél összes változata örökre megőrzésre kerüljön (az 50GB mailbox kvótán felül...)

Üdv,
Marci
A Microsoftnál dolgozom.

Államosítás = magántulajdonban álló javak állami tulajdonba vétele

Ha az állam megvesz valamit, az is államosítás, nem attól függ az államosítás, hogy kényszerből, vagy önként történik, vagy fizettek érte e vagy sem.

Szerintem te a kollektivizálásra gondolsz.

Gusztustalan reklamnak tunhet, de pont errol volt szo az AWS User group meetupon. Az O365-hoz is ugyanugy kellenek uzemeltetok, mert egyreszt nagyon nem egyszeru dolgozni vele, raadasul a helyben marado szoftverek integralasat/felugyeletet szinten meg kell oldani, tehat a felhobe migralas nem jelenti azt, hogy az xch gazdakat ki kell dobni, hiszen - mivel az O365 is xch alapu - rettenetesn hasznos tudassal rendelkeznek az uj kornyezetben is.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

hmmm.... most egy kicsit megzavarodtam. tehat:
- ugyanannyi ember kell az uzemelteteshez mint eddig
- ugyanugy kell tamogatas a usereknek mint eddig
- nem fog kevesebbe kerulni a dolog?

ha a fentiek igazak lennenek, akkor:
- kiadok egy rakas penzt a havi/eves diju o365-re az egyszeri dij helyett (ismerek olyan ceget ahol access2003-mal dolgoznak es nem is tervezik a valtast)
- atkepzem ra az embereket (igen, mancikara is gondolok)
- rabizom egy kulsos cegre minden adatomat es bizok benne, hogy kifizeti a karomat ami az o hibajabol bekovetkezo allasidobol szarmazik
- rabizom egy kulsos cegre minden adatomat es bizok benne, hogy nem fogja holnap mindenki megismerni a 4chan/twitter/akarmirol ezeket az adatokat
- bizok benne, hogy a netszolgaltatom az evi 90%-os rendelkezesreallast es a 72 oras javitast nem hasznalja ki maximalisan

ezek bizony gazdag elonyoknek tunnek a felho-alapu akarmi mellett.

You missed the point.

Nem azt mondtam, hogy nem fog kevesebbe kerulni a dolog. Azt mondtam, hogy a felho nem jelenti azt, hogy az uzemeltetoket mind ki kell rugdosni, mert nem lesz rajuk szukseg.

Azonban a hardver TCO-javal kevesebbe kerul a rendszer fenntartasa, hiszen az O365 havidija osszessegeben is joval kevesebb, mint amit egy ugyanolyan kepessegu es rendelkezesreallasu rendszer uzembentartasara koltenel, figyelembe veve az avulast, a kulonbozo alkatreszek cserejenek szuksegesseget, ilyesmiket.

Valojaban egy itthoni kis- vagy kozepvallalatnak jobban megeri a felhobe koltoznie, mint mocskosdraga vasakat meregdragan uzemben tartani. 50-100 foig egyszeruen nem fizetodik ki az a hardver, ami a kiszolgalasukhoz szukseges. Ha azt veszed, hogy egy magas rendelkezesreallasu hardvercsomag koltseget 1-2 millio alatt meguszni egyaltalan nem lehet, akkor eleg egyszeruve valik a matematika.

A felhobe koltozessel elsosorban eroforras szabadul fel, az uzemeltetok idejet nem koti le az Exchange szerver adminisztracioja. Egy KKV-nal jellemzoen 1-3 rendszergazda van (ha eppen nem outsourcinggal oldjak meg a dolgot), akiknek amugy is eleg sok mindenre kell fokuszalni, ha valamire epp nem kell, akkor van idejuk massal is foglalkozni. Itthon raadasul kulonosen jellemzo az alultervezes, vagyis hogy kevesebb embert alkalmaznak, mint kellene, mert magasak a berkoltsegek. Sok kisvallalatnak mar az is problema, ha a rendszergazda epp megfazott, mert nincs helyettesitese.

Ami az adatok biztositasat illeti, nem biznod kell. Ha regisztralsz valahova, van egy ASZF/TOS, amit elfogadsz, meg ha nem is olvasod el. Az abban foglaltak mindkettotoket kotnek, ha abban az van benne, hogy a ceg fizet az adataid megsemmisulese, vagy a szolgaltatas elerhetetlensege miatt, akkor a ceg fizetni is fog, hiszen nem feltetlen erdeke a peres ut (ha senkinek nem fizetne, akkor hirtelen mocskos draga lenne fenntartani az ugyvedhadsereget, mert folyamatosan dolgoznanak).

A bizalmat illetoen... megforditom a dolgot. Neked van egy munkaadod, aki ismeretlenul a kezedbe adta a ceg kritikus adatait, azzal a feltetelezessel, hogy masnap nem fogja azokat "holnap mindenki megismerni a 4chan/twitter/akarmirol". Szerinted rossz dontest hozott? Az o szemszogebol mennyire bizhatott benned? Ha beperel is, a nyilvanossagot visszavonni nem lehet ugyebar. Pontosan ugyanez all a Microsoft/Google/Amazon/barakarki altal uzemeltetett felhos infrastrukturakra. Az ezekbe valo migracio majdnem pont ugyanazon a dontesi mechanizmuson alapul, mint egy uj rendszergazda felvetele. Raadasul csak egyszer deruljon ki az ilyesmi, az hatalmas presztizsveszteseg lenne. A cegek altal tarolt adatok ugyanis nem meztelen celebfotok, hanem penzben merheto erteket kepviselnek, nem vetheto ossze a kettonek a fontossaga.

Raadasul a felhos rendszereknel ugyanugy elerheto a fokozatos migracio, mint egy rendszergazda eseteben a fokozatos felelossegnoveles. Nem kell rogton a ceg legtitkosabb adatait odaadni. Kezdetnek eleg, ha csak a ceg nyilvanos dokumentumait teszed ki sharepointra.

Persze, ehhez konstruktivan kell hozzaallni a kerdeshez. Ha mindent abbol az allaspontbol szemlelek, hogy mindenki az en adataimra utazik, akkor tenyleg csak az lehet a jo dontes, ha kihuzom az internet kabelet a falbol, minden mas csak fatalis hiba.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

azt azert tegyuk hozza a meretgazdasagossaghoz, hogy vannak olyan teruletek, amely szereploi merettol fuggetlenul nem vihetik ki a falakon kivulre a levelezesuket, igy nincs jobb opcio, mint kiepiteni a privat felhot hazon belul.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Már megosztja az USA a PRISM lehallgatási adatokat az EU-val?
Mert ha nem akkor megint fogalom nélkül sikerült elismernie az EU-nak valamit. :-)

A "józan cég" definíció szerint a többségre és nem a különcökre vonatkozik ebben a méretben. MKB bank "Tudomásom szerint mi vagyunk az első és egyetlen bank Magyarországon" nem tartozik ide.

Mielőtt elszállnál az Office 365 képzelt csodáitól pár tény:
- A német (bajor) tulajdonos nemrég eladta az MKB bankot a magyar államnak
- Nem jó kedvükben adták el, belátták esélyük sincs a törvényhozást maga mögött tudó magyar állammal szemben
- Hagytak hátra pár bombácskát ajándékként az új tulajdonosnak. Például jól megemelték a számlavezetéssel kapcsolatos díjakat (átutalás stb) de a döntés csak később, az állami tulajdonba-vétel után lépett hatályba.

Természetesen vittek minden mozdítható értéket. A szervereik pedig még használtan is értéket képviselnek. Levelezésnek lennie kell, így az állam kapott ficsi felhős Office 365-öt aminek fizetheti az díjait. Vagy vehetnek új szervereket.

- Nem jó kedvükben adták el, belátták esélyük sincs a törvényhozást maga mögött tudó magyar állammal szemben
- Hagytak hátra pár bombácskát ajándékként az új tulajdonosnak. Például jól megemelték a számlavezetéssel kapcsolatos díjakat (átutalás stb) de a döntés csak később, az állami tulajdonba-vétel után lépett hatályba.

Hát, ahhoz képest, hogy a bank értéke a mínusz 60 milliárdot is "túllépte" (értsd: eladás előtt berakott 80 milliárdot az eladó a kasszába, majd ezek után 17 milliárdért megvették tőle az így már nem üres kasszájú bankot), tulajdonképpen mindegy, hogy hány "bombácskát" hagytak hátra, mivel már buktak rajta egy laza 11 számjegyű összeget, ehhez képest elhanyagolható bármilyen "bombácska"...
Ennek fényében pedig az "esélyük sincs a magyar állammal szemben" helyett a valóság az, hogy az a bank már egy fillért sem ért, így akkor adták el, amikor valakit találtak, aki hajlandó volt egyáltalán megvenni. Persze megtehették volna, hogy egy fillért sem adnak a banknak, és lazán hagyják csődbe menni, akkor spóroltak volna a bajorok 60 milliárdot.

"A "józan cég" definíció szerint a többségre és nem a különcökre vonatkozik ebben a méretben"

Akkor aki különc vagy kisebbségben van éppen, az nem józan?
És melyik méretben van ez máshogy?
Komolyan nem értem, hova akarsz kilyukadni!

Nem kérdés, hogy jópár magyar nagyvállalat használ Office365-öt.
Továbbá az is tény, hogy jópár céggel beszélgettem a levelek compliance célú megőrzéséről és a kapcsolódó e-Discovery lehetőségekről.

A többi nem vág a témába.

Üdv,
Marci

jópár céggel beszélgettem a levelek compliance célú megőrzéséről és a kapcsolódó e-Discovery lehetőségekről.

a beszamoloik engem is erdekelnenek :-) Btw. a 3rd party email archivalasban utazo vendor-ok azt terjesztik, hogy a microsoft archive mailbox nevu feature-je (felteve, hogy errol beszelsz) egy jo lepes az email archivalas vilagaba, de tavol van attol, hogy egy ceg szamara teljes koru megoldast adjon. bar az is lehet, hogy felnek, hogy ha a microsoft a topikban egy nagyot villant, akkor lehuzhatjak a rolot...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nem az archive mailboxról beszélek, az erre nem jó.

Az egyik a litigation hold (legal hold): http://help.outlook.com/en-us/exchangelabshelp/ff628734
valamint http://technet.microsoft.com/en-us/library/ff637980(v=exchg.150).aspx
Ennek segítségével, a cikkben részletezett finomsággal megőrizheted a mailbox tartalmát/annak egy részét a Felhasználó szándékától függetlenül.

A másik az ehhez kapcsolódó In-Place eDiscovery: http://technet.microsoft.com/en-us/library/dd298021(v=exchg.150).aspx#h…
Ezzel számos mailboxot (sőt, SharePoint szervereket is) átfogva kiterjedt kereséseket végezhetnek az arra jogosultak bizonyos tartalom után, aminek végeredményét egy letölthető .PST-ben állítja elő számukra a rendszer.

Személyes véleményem az, hogy "a Microsoft a topikban már nagyot" villantott.

Ezeket a funkciókat a saját infrastruktúrán futtatott Exchange Server is tudja, persze ott a megfelelő tárkapacitást is az Ügyfélnek kell biztosítani.

Üdv,
Marci

kossz az infokat, atolvasgatom azokat a linkeket. Btw. van olyan tool, amivel EML file-okbol pst-t lehet kesziteni? A legjobb egy cross platform, esetleg script nyelven megirt megoldas lenne. A feladat az, hogy linuxon keszitsek pst file-okat.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nem gondoltam komolyan. Sajnos pst olvasashoz nem talaltam meg en sem hasznalhato eszkozt, ami azt hirdette magarol, hogy tudja kezelni a pst-ket outlook nelkul, az vagy nem fordult, vagy nem mukodott, es mindegyik halott projekt volt. (Volt egy rovid idoszakom, amikor tartottam itthon egy Exchange szervert, es jo lett volna nem egyesevel kimigralni a levelezesemet belole manualisan).
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

"Azt nem tudom pontosan, hogy a "józan cég" definíciója micsoda, de azt gondolom, hogy az MKB Bank ebbe a kategóriába tartozhat."
Az elmult evekben az MKB hatalmas veszteseget halmozott fel, mert felelotlen ingatlanhitelezesei voltak a nagyvallalati szektorban, rossz a hitelportfolioja, a tulajdonos BayernLB el is adta a bankot a magyar allamnak.
2010-2013 kozott 400 milliardos veszteseget sikerult csinalniuk. Ovatosan a megitelesevel :)

Azt, ha a bank gazdasági igazgatója mondaná ezeket az érveket, az számomra sokkal elfogadhatóbb lenne. Az hogy ezt a bank "IT üzemeltetési és bankbiztonsági ügyvezető igazgatója" mondja több ponton is érdekes.
Minek az ügyvezető igazgatója?
Miért a gazdasági szempontok neki a fontosak?
Miért nem az informatikai, és bankbiztonsági előnyeit emeli ki?
Pontosan miből áll a 20-30% vajon tényleg az infrastruktúra fenntartásából?

Aki ilyen döntést hoz, az akárkihez elköltöztetheti a levelezését (outsource). Ennek nem kell szükségszerűen felhő alapúnak lenni.

Szóval számomra ez a kijelentés szakmaiatlan. Mert persze egy fontos paraméter a gazdasági hatékonyság az IT-ben, de ha nem tudja eldönteni ez e a jobb vagy másik (a kijelentés alapján saccolom) akkor itt nem volt komoly előkészület.

Mármint melyik részével van bajod?
Számomra az általad átadott információk közül egyet nem dolgoztam fel. Ki mondta (ember szintjén). Pozíció szinten vizsgáltam a kijelentést, és a tettet és a következményeit. Ha a fentit én mondom, akkor is kétségbe vonom. Vagy a közlésed rossz, hiányos, vagy ezzel van valami gond.

-Érdekesnek találod, hogy a bank "IT üzemeltetési és bankbiztonsági ügyvezető igazgatója" számára fontosak a gazdasági szempontok. Régóta nem láttam "pozíció szinten" hasonló embert, akinek ne lennének fontosak ezek (is).
-Bizonyos dolgokról egyáltalán nincs információ (se pro se kontra - ez csak rövid idézet egy cikkből), mégis állítod, hogy szakmaiatlan a kijelentése.
-"ha nem tudja eldönteni ez e a jobb vagy másik": feltételezés, nem tudom, min alapul.
-"akkor itt nem volt komoly előkészület.": a feltételezésen alapuló ítélet.

Üdv,
Marci

Nem tudom leírni egyszerűbben. Én azt várom egy IT és Biztonsági vezetőtől (az ügyvezető szót nem értem ez esetben) hogy ha kijelent valamit az ő felelőssége alá tartozó projektről, akkor az nem az, hogy jóval olcsóbb. Hanem az, hogy olcsóbb de a biztonságot nem befolyásolta, vagy a biztonság növekedett és nem azt, hogy egy üres és általános 20-30%-os megtakarítást értünk el kijelentést tesz.
A kijelentés nekem inkább tűnik üzletpolitikainak mint szakmainak. Márpedig, ez nem az a fórum ahol az üzletpolitikával nagy sikert lehet aratni.

Felreertetted. Nem az a problema, hogy fontosak neki a gazdasagi indokok is. Gyakorlo uzemeltetokent nekem is fontosak a gazdasagi szempontok, de eszembe nem jutna egy szervert ugy ajanlani ki egy szerepkorbe, hogy ez olcsobb, ezt vegyetek. Mindenkeppen szerepelne a hivatalos velemenyemben az, hogy jo vagy nem jo a celra, kell kompromisszumot kotni vagy nem kell. Attol lesz valaki felelos informatikus, hogy meg amikor gazdasagi indokokat hangsulyoz, akkor is megemliti a szakmai szempontokat. Az informatikaban ugyanis a gazdasagi szempontok legfeljebb masodlagosak lehetnek. Ez nem WC-papir, hogy az olcso is pont ugyanolyan jo, nalunk az olcsobb a legtobb esetben valamilyen kompromisszumot jelent, ami esetleg nem erinti a ceget, de a kompromisszum akkor is jelen van, lete letagadhatatlan teny.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Kerdezd meg ugyanezt barmelyik irodahaz gazdasagi osztalyan.

(en is tudom, nem veletlenul ragaszkodok egy markahoz, meg ha egyre trukkosebb is hozzajutni).
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Miert kellene ismernie egy semmibol jott valakit? Ertem, hogy Microsoftos szemmel a 10 millios lakossag nem egy nagy szam, de ettol meg nem ismer mindenki mindenkit. Ez nem egy tizlakosu falu, akkor se, ha Amerikahoz vagy Kinahoz kepest akkoranak tunik.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Szerintem nyugodtan belinkelhetnéd, hogy milyen szerződéses feltételeket vállal a Microsoft, ha egy üzleti ügyfél (pl. a bank) odavinné a belső, bizalmas adatait, amikkel kapcsolatban a banknak akár korlátozás nélküli kártérítési kötelezettsége keletkezhet, ami miatt rossz esetben akár csődbe is mehet az adott bank. Érdekelne, hogy vajon a hírhedten semmilyen felelősséget nem vállaló szolgáltatók sorából kilóg-e a Microsoft, mondjuk pl. azzal, hogy felső korlát nélküli kártérítési kötelezettséget vállal a saját szerződésszegése esetére.

Az SLA-t itt találod, "Service Level Agreements for Microsoft Online Services (SLA)" alatt: http://www.microsoft.com/licensing/products/products.aspx

Az SLA-ért pénzügyi felelősséget vállalunk, de felső korlát nélküli kártérítési kötelezettséget nem. Ez utóbbi tudtommal sehol nem volt showstopper. Pont a Bankoknál relatíve erős hagyománya van az adatkezelési szabályzatoknak és az üzletmenet-folytonossági terveknek.

Itt megtalálsz mindent a biztonság témából: http://office.microsoft.com/en-us/business/office-365-trust-center-clou…

Üdv,
Marci

Nem az SLA-ért kellene kiemelt felelősséget vállalni, hiszen arra, hogy nem megy a rendszer, amúgy is készülnie kell a banknak. De mit tesz akkor, ha mondjuk a szerződéses feltételeket nem tartja be a szolgáltató? Pl. a bizalmas adatokat (email) kiadja egy hibázó alkalmazottja a szolgáltatónak? Az nem SLA kérdése, hanem szimplán szerződésszegés. Aminek akár akkora vonzata is lehet, amitől csődbe megy a bank.

Miert nem eletszeru? A nav ados toplistan is szerepel maganszemely 2 milliardos adohiannyal. Magancsod intezmenye viszont nincs, a tartozas nem evul el, igy elete hatralevo reszeben dolgozhat az okozott kar megfizetesen. Avagy a rabszolgasag a modern korban (tobb szabadsagot von el, mint egy tobb eves bortonbuntetes).

Nálam a munkaszerződésben maximálva van a károkozás esetén kiszabható max. bünti. Asszem négy hónapnyi fizu. Vagy kevesebb. Vagy nemt'om, de semmiképpen nem több. Ami, belegondolva, hogy mi a munkám, röhejesen kevés.

Ha nagyon nekigyürkőznék, tudnék egy sok számjegyű problémát okozni. :)

Azok szerintem nem munkavállalók. Persze, hogyne lenne néhány eset amikor rátolnak egy ilyet valakire vagy valamire, de akkor sem életszerű. Ettől függetlenül tetszőleges szervezet egy tetszőleges másiktól vagy akár magánszemélytől nem várhatja, hogy korlátlan mértékű felelősséget fog neki adni vagy ha esetleg ad, akkor az bármilyen módon érdemben realizálható lesz. Itt legfeljebb arra lehet számítani, hogy egy nagyobb és gazdagabb szervezett jóval potensebb kártérítéskor.

Hol felelt ez meg teljesen az EU adatvedelmi torvenyeinek? Az adatok exportalasanal? A teljes banki kommunikacio birtokaban a gazdasagi kemkedes es erdekervenyesites egeszen uj lehetosegei nyilnak meg. Biztosan jo otlet egy ilyen bank szolgaltatasait hasznalni?

"The analysis covers the engagements reflected in the model clauses
2010/87/EU but not its Appendixes (description of the transfers of data and of the technical and organizational security measures implemented by the data importer). According to usual implementation of the model clauses, these Appendixes need to be completed by Microsoft and its clients when signing the contract and may be analyzed separately by the Data Protection Authorities
."

"‘the data importer’ means the processor who agrees to receive from the data exporter personal data intended for
processing on his behalf after the transfer in accordance with his instructions and the terms of the Clauses and who is
not subject to a third country’s system ensuring adequate protection within the meaning of Article 25(1) of Directive
95/46/EC;"

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:039:000…

Miert megy a mely hallgatas arrol, melyik torveny ervenyesul ha az adott orszag torvenye konfliktusba kerul az EU adatvedelmi torvenyeivel? Avagy patriot act & national security letters.

http://hup.hu/node/135819#comment-1789228
http://hup.hu/node/121780#comment-1585324

Senki sem fog senki felé korlátozás nélküli kártérítést vállalni, ezzel mindenhol tisztában vannak. Be lehet próbálkozni, elém is tettek érdekes pontokat tartalmazó szerződést és majdnem fejbe is vertük a "kedves" jogiosztályt. Aztán rájöttek, hogy elolvassuk amit aláírunk és sikerült normális szerződést kötni. A másik, hogy azt is kikötik, hogy melyik bíróság és jog szerint (pl. X állam az USA-ban) van az ASZF és ez rögtön azt is jelenti, hogy egy hazai Ügyfél alapvetően vesztes helyzetben van a költségek és egyebek miatt, ha perre kerül a sor.

> 100x lassabb lett (nem koltoi tulzas, 0.1s vs 10s).
Konkrétan ez milyen idő? Levél küldése és megérkezése közötti? Levelezőkliens betöltődése?

> A tovabbi hatranyokrol meg mar ne is vitatkozzunk.
Pedig vitatkozhatnánk, mert _személyesen_ nem ismerek elégedetlen Office365 felhasználót (pedig elég sok user van az ismerőseim között - szerk: ja, meg én is az vagyok), mindig csak a fórumokon olvasom, hogy szar.

Nem lehet fekete-fehéren állást foglalni a felhő mellett vagy ellen, pláne nem a konkrét helyzet ismerete nélkül, de ezek tipikusan a leggyengébb érvek. Az áramszolgáltató és ISP nem kezeli az adataidat (utóbbi is csak továbbítja, legfeljebb annyit lát belőle, amennyit engedsz). Azon adatokat, amiken a cég bevételei múlnak. Rövid és hosszú távon egyaránt. Konkrétan értékesebb, mint a bankban tárolt egyenleg.

Nem ertem mi vitte ra a rendszergizdakat erre a lepesre. Pedig van szerverunk, nem gyenge.

valoszinuleg nem a rendszergazdak talaltak ki, hanem a menedzsment. De valoszinuleg azt sem erted, mi fan terem egy vallalati levelezes mukodtetese...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

szükség esetén nyomtalanul lehet törölni emaileket. :-)

iiiiii...nem. Egyreszt egy level nem csak a 'jozan cegnel' van meg, hanem annal is, aki(nek) kuldte(k). Ha meg ez raadasul ki is derul egy problemas ugyben, akkor hirtelen a ceo es lefele a taplaleklancban egeszen hozzad, aki effektiven nyomkodtad az ecetes DEL gombot, megtapasztalja milyen az, amit az angol ugy fejez ki, hogy the shit hits the fan.

Egyebkent a hivatkozott ceg email archivalasban is utazik, es varhato, hogy idovel hozzank is beszivarog az, hogy az emaileket archivalni kell, ahonnan nem opcio az onkenyes torles. Szamos olyan eset van amugy, amikor az email hianyat ugy ertekelte a birosag, hogy a vadlottel akarta tuntetni a bizonyitekokat, magyarul buko.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Általában mindkét fél érdekelt az ilyen emailek törlésében. Ha mégis kiderülne csak a szokásos magyarázat van: "fogalmam sincs ki ült a gép előtt amikor megnyomta valaki a del gombot"
Imho nem ütközik semmilyen törvénybe emailek törlése amíg nincs eljárás a bank, cég ellen. Ha minden emailt kötelezően meg kellene tartani, akkor még a spameket is tárolni kellene.

Arról nem is beszélve, hogy diszkek, szalagok, számítógépek a legjobb helyeken is szoktak tönkremenni, figyelmetlen rendszergazdák mindenhol vannak, betörések pedig a legnagyobb cégeknél is előfordulnak.

A személyes véleményem, hogy azok a cégek, akik emailben konspriálnak, meg is érdemlik, hogy megszopják. Az ilyesmit élőszóban, védett helyiségekben kell megvitatni, szigorúan felvételek és nyomok nélkül.

nalunk ugyan meg nincs ilyen torveny, de a nyugati ortodox orszagokban az kapasbol buko, ha azt mondod, hogy tonkrement a szamitogep (lol-kategorias), figyelmetlen volt a rendszergazda (kerem, faradjon a hr-osztalyra), elofordulnak betoresek (vannak worm drive-ok is). Szoval, amiket felsoroltal, azok lol-kategorias nevetseges kifogasok

azok a cégek, akik emailben konspriálnak

a legtobbszor nem errol van szo, hanem egyszeru ptk-s vitas ugyek ceg vs. alkalmazott, ill. 2 ceg kozott.

Az ilyesmit élőszóban, védett helyiségekben kell megvitatni, szigorúan felvételek és nyomok nélkül.

hat persze...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

es azon kivul hogy 'lol-kategorias'-nak titulalod, mi tortenik a fenti esetekben a nyugati ortodox orszagokban? azonnal 5 ev kofejto mert csotores kovetkezteben leazott a szerverterem? vagy mert szakmunkasok eppen azt az irodat pakoltak ki mindenestul ahol a kerdeses dolgok voltak? ez elegge lolnak hangzik meg innen magyarorszagrol nezve is. (pedig itt barmi megtortenhet.) netan nyugati ortodox orszagokban torveny irja elo az emailek orok idokre (na jo, 20 evre) torteno archivalasat?

tudsz hozni konkret peldat erre? esetleg link? arra van tippem hogy megy nalunk, de hogy mukodik ez mondjuk tolunk nyugatabbra?

Nagyon leegyszerűsítve: http://blog.jatheon.com/bid/133417/3-Point-Email-Overview-of-Sarbanes-O…

Húsz évig terjedő börtönnel és pénzbüntetéssel fenyegetve...
...és Magyarországon is találsz céget, akire érvényes!

Itt például egy $9M büntetés: http://www.reuters.com/article/2013/05/21/us-finra-lpl-idUSBRE94K0M9201…

Üdv,
Marci

mivel az informatikaban _nincs_ atombiztos vedelem barmi ellen is ezert kisse tulzonak tartom a dolgot. persze a nav is siman kijelenti nalunk, hogy 'nem eletszeru'. gondolom a hivatkozott torveny kisebb cegekre nem vonatkozik? velemenyem szerint erdekes lenne ha minden vallalkozas/ceg/non-profit egyesulet kotelezve lenne ilyen szintu adatbiztonsag megvalositasara.

A SOX konkrétan ezen cégekre vonatkozik: "SOX applies to all public companies in the U.S. and international companies that have registered equity or debt securities with the Securities and Exchange Commission and the accounting firms that provide auditing services to them."
http://www.sox-online.com/basics.html

Természetesen más cégekre is vonatkozhatnak olyan törvények, szabályozások, akár belső szabályzatok, amik az e-mailek megtartását igénylik.

Üdv,
Marci

Természetesen más cégekre is vonatkozhatnak olyan törvények, szabályozások, akár belső szabályzatok, amik az e-mailek megtartását igénylik.

arrol nem is beszelve, hogy erosen valoszinu, hogy a nyugati szabalyozas (kotelezo email archivalas) elobb-utobb hozzank is atszivarog, annal inkabb is, mert ez nem csak egy compliance tool, hanem egy produktivitast is novelo eszkoz...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Erre csak annyit mondanék, hogy illúzió a nyugat felé. Sokszor szakmaiatlanabb hozzáállással találkozik az ember. Akár egy DR terv akár egy egyszerűbb mentési folyamat ellenőrzésnél. Meg nem nevezett cég meg nem nevezett országban direkt kérte, hogy bizonyos feladójú és bizonyos címzettű levelezése maradjon ki a mentésből. Kaptak külön domaint. Nincs mentve.

nalunk ugyan meg nincs ilyen torveny, de a nyugati ortodox orszagokban az kapasbol buko, ha azt mondod, hogy tonkrement a szamitogep (lol-kategorias), figyelmetlen volt a rendszergazda (kerem, faradjon a hr-osztalyra), elofordulnak betoresek (vannak worm drive-ok is). Szoval, amiket felsoroltal, azok lol-kategorias nevetseges kifogasok

Nézd, én a valóságot soroltam fel. SOX alá eső cégeknél is történnek ilyenek, kidolgozott és papíron elég jól betartatott policy-k ellenére is.

Hiába tartod az összes dobozos szoftvert up-to-date állapotban, gondolom nem mondok újat azzal, hogy ennek ellenére is folyamatosan lesznek ismert sérülékenységek bennük. A belső alkalmazottak által elkövetett dolgok ellen pláne sokkal kevésbé tudja megvédeni magát egy cég, aztán utána már hiába rúgja ki őket, vagy próbálja őket szénné perelni, az nem biztos, hogy sokat változtat a tényen, hogy valami adat kikerült/megsemmisült.

A SOX is csak arról szól, hogy ne legyen előre látható sérülékenység és SPOF a cég működésében - de ha összefog pl. a jóváhagyó a jóváhagyást kérővel, vagy a rendszergazda a mentést fizikailag kezelővel, akkor ketten simán meg tudják hágni a rendszer szánt szándékkal.

azok a cégek, akik emailben konspriálnak

a legtobbszor nem errol van szo, hanem egyszeru ptk-s vitas ugyek ceg vs. alkalmazott, ill. 2 ceg kozott.

Ptk-s ügyekben nem jellemző az, hogy a cégből ki lehessen verni egy belső levelezést. Büntetőügyek, versenyhivatal, ilyesmiknél van erre reális esély. Aki pedig ilyenekben utazik, az a minimum, hogy tudja, mikor lépi át a törvényesség határait, és akkor ennek megfelelően gondoskodjon, hogy ne maradjanak utána nyomok. Ellenkező esetben meg ha kiderül a dolog, akkor ne csodálkozzon, hogy előveszik - és egy nagyobb, tőzsdei cégnél a következmények is durvábbak lesznek.

nem azt mondom, hogy letezik a 100.00%-os biztonsag, de gondolj bele: lesz egy ugy, amiben a birosag emaileket ker be, de hogy-hogy nem, hat 'nyilvan csakis veletlenul' pont akkor megy tonkre a szamitogep (=mail szerver?). OK, ennek is megvan a maga valoszinusege, de nem tennek ra nagyobb osszeget, hogy a biro megerto lesz.

ennek ellenére is folyamatosan lesznek ismert sérülékenységek bennük [...] . A belső alkalmazottak által elkövetett dolgok ellen pláne sokkal kevésbé tudja megvédeni magát egy cég

jogos. A kerdes az, lehet-e ezek kockazatat mersekelni. Mivel az email barmelyik random ceg eleteben elegge mission critical, ezert - a kockazatokat is figyelembe veve - az nem elfogadhato valasz, hogy shit happens. Mert valoban `tortenik`, de ilyenkor mindig fel fog merulni az a kerdes, hogy vajon el lehetett volna kerulni? Es ha a valasz az, hogy igen, raadasaul kis raforditassal, akkor te vagy a hunyo. Nyilvan nem mindegyik ceg engedheti meg maganak, hogy 2 adatkozpontja legyen, azt sem, hogy a mail szerverrol egy felhos szolgaltatohoz nyomja fel masolatban a leveleit, azt sem, hogy legyen minden levelrol egy masolat egy masik rack szekrenyben levo gepen, azt sem, hogy legalabb szalagos, whatever mentes legyen a mail szerverrol, azt sem, hogy legalabb raid legyen a mail szerverben, etc, lehet meg ragozni a dolgot.

Az adott cegtol fugg, hogy a listaban melyik pontnal kezdi a hasat fogni a rohogestol, de pont azert vannak a compliance szabalyok akar iparagra lebontva, hogy minel kisebb esellyel kovetkezzen be adatvesztes, es akar odaig is elmegy, hogy eloirja x cegnek, hogy legyen DR site-od egy masik szolgaltatonal, stb.

Ptk-s ügyekben nem jellemző az, hogy a cégből ki lehessen verni egy belső levelezést.

erosen fugg az adott orszag jogi kornyezetetol.

Aki pedig ilyenekben utazik, az a minimum, hogy tudja, mikor lépi át a törvényesség határait, és akkor ennek megfelelően gondoskodjon, hogy ne maradjanak utána nyomok.

igen, aztan vagy sikerul, vagy nem. Az egyik csi sorozatban mondta az egyik helyszinelo a masiknak, hogy hat itt bizony kitakaritottak. Mire a masik: de nem csi-takaritas volt. Arrol nem is beszelve, hogy itt is az ember szokott lenni a leggyengebb lancszem...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Erről az egészről csak az jut az eszembe, hogy mi lesz pl abban a teoretikus esetben, ha
- pl. az MKB Bankhoz hasonló pénzügyileg jelentős és értékes adatot felhőben tároló company adatai kikerülnek, mert az üzemeltetett felhőben 0day volt, hekkerek felnyomják és véletlenül nem egy anyagilag érdekelt banda hanem egy amolyan wikileaks-es társaság aki kinyomja publicba az adatokat. A kár felmérhetetlen.. az MS felhő sérülékenysége okozta a problémát... már azt sem mondhatjuk, hogy a banktól kerültek ki az adatok... én nem hiszem, hogy ezek a pénzügyi cégek anyagi felelősségvállalás nélkül kiadták volna az adataikat a felhőbe... egy ilyen esemény miatt akár le is húzhatják a rolót ha kellően nagy értékű adatokról lenne szó egy kellően nagy értékű cég esetében...
ez lesz a felhő-korszak vége? mondjuk egy ilyen sandworm jellegű cucc proliferációja esetén....

Mi ebben a felhő-specifikus? Tán a helyi rendszert nem lehet így támadni és a megszerzett információkat kijuttatni?
Vajon a helyben üzemeltetett vagy a felhős rendszerek állnak jobban biztonsági beállítások, szerepkör elhatárolás, patchelés sűrűsége, monitoring alaposságga és a környezet szabványos kialakítása és rendszeres auditja tekintetében?

Üdv,
Marci

Tényleg? Ezt honnan tudod ilyen biztosan?
És mi a helyzet a többi hírszerzéssel? Miért van az amerikai kitüntetett helyzetben számodra?

A hírek szerint Merkel telefonját is lehallgatták...
Pedig arra alighanem jobban figyeltek mint egy átlagos géptermi mailszerverre.

Én nem sokat tudok az ilyen szervezetek tevékenységéről, de gyanítom, ha valaki rendelkezik is infóval, nem itt a hupon fogja kiteregetni. ;-)

Pontosan az információ hiánya miatt nem tartom értelmesnek az azon való töprengést, hogy a vilag titkosszolgálatainak hol van nehéz dolga.

Üdv,
Marci

national security letters? es nem csak az amerikai clouddal van baj

"A U.S. judge has ordered Microsoft to turn over a customer's emails stored in a data center in Ireland, despite European Union laws saying that only the court local to that jurisdiction can order such a thing.

According to the judge, since Microsoft is headquartered in the U.S. and simply stores data overseas, foreign subsidiary companies of Microsoft are applicable to U.S. law as well.

"It is a question of control, not a question of the location of that information," U.S. District Judge Loretta Preska said in the ruling."

www.out-law.com/en/articles/2014/august/microsoft-launches-further-appe…
http://www.zdnet.com/microsoft-ordered-to-hand-over-overseas-email-thro…
http://www.techtimes.com/articles/11969/20140805/ny-judge-shoots-down-e…

Akkor egy másik hasonlatpárt mondok:
1. Bemegyek a bankba, bérelek egy széfet, elhelyezem a roppant értékes értéktárgyaimat benne amiért a bank garantál egy összeghatárig.
2. Banki adatok felhőbe tárolása esetén akár egyszerű levelezésnél is rengeteg forintosítható tranzakcióról folyik eszmecsere, akvizíciók, mindenféle tranzakciók óriási volumenekben, ezek az adatok gyakorlatilag ugyanolyan értékesek mint az általam széfben elhelyezettek csak sokkal nagyobb volumenben.

Eddig a bank maga felelt ezek biztonságáért, a saját szerverein őrizte ezután egy másik céggel kell nyilván egy megfelelő felelősségvállalással kipárnázottan megállapodnia a felhőben tárolásról, ami kiterjed arra az esetre is, ha mishap van, ki miért felel milyen összegig (számomra elképzelhetetlen, hogy a szokásos disclaimeres formulát banki adatok tárolása vonatkozásában megegye egy bank) Mishap ugyanis előbb vagy útóbb így is úgy is lett volna csak most már ha felhő, akkor a felhős cég is felelős az adatokért és az azok kiszivárgásából eredő károkért. Egyszerű polgári jogi kártérítési felelősség.

Erre próbáltam utalni, hogy egy pénzügyi intézmény ezzel a lépéssel gyakorlatilag komoly felelősséget testált másvalakire is, akinek helyt kell állnia ezekért ezután. Eddig a bank felelt egyedül mindezekért. Ez nem ugyanaz, mint rákosrekettyei asztalosüzem levelezése, aminek a feltörése nem tud nemzetgazdasági méretekben is jelentős károkat okozni ...

Oszt a végén még egy bank fogja birtokolni az M$-t is :) De reakciódból látom nincsen humorérzéked, de a lényeg az, hogy ebben a szektorban komoly felelősséget is elvárnak a "beszállítóktól", mivel ilyen jellegű az "üzem".

A kérdés az az, hogy ezekben az esetekben egy esetleg jövő bank-felhő-info-gate esetén a kárt ki viseli? Az adatkezelő felhőszolgáltató? A bank? a betétes? Az állam? Valamelyik fél biztosítója? Milyen arányban? Szerintem szép diplomamunka lenne.

Nem olyan egyszeru valoban nyomtalanul torolni az emaileket. (ez alatt azt kell erteni, hogy nyomozati eszkozok segitsegevel sem szerezheto info).
Strategiai hiba barmilyen uzletileg kritikus informaciot harmadik felre bizni. Barmilyen kesobbi vita eseten a valosag rekonstrukcioja ezen informaciok alapjan tortenik - es nem mindegy ki irja a narrativat hozza. Ugyanazt az informaciohalmazt sokfelekeppen be lehet mutatni...

Tanulsagkent (a lehallgatasi botrany elotti idokbol):
http://hup.hu/node/121780

Leginkább DAG-ot, vagy hasonló cluster megoldást, amivel elérhető az, hogy ha akadozik a felhő, vagy az internet, attól még házon belül menjen a levelezés. Elhiszem én, hogy a felhő rendelkezésre állása mennyire jó, de lekopogom, a belső levelezőrendszerünk még nem állt le magától sok év alatt, ellenben a felhővel és az internettel. Amit alapból adnak, a hibrid mód, ott egy user vagy csak felhő, vagy csak onprem, tehát nem véd az előbb említett gondok ellen. Ettől nekünk jobb, ha házon belül + egy hostingban van egy Exchange cluster két lába.

--

Az akkor fog menni, hogy ha Exchange szervert veszel és nem felhőt. Ezt viszont bármilyen VPS-el vagy fiziakai szerverrel is meg lehet oldani, nem csak "felhőssel". amit Office365 szinten kapsz, az eleve DAG-ozott meg mindenezett, EU-n belül több lokációval megoldott. Az megint egy érdekes kérdés, hogy már eleve a rendszer bonyolultságából adodóan jöhetnek meglepetések és ez a privát DAG-os szolúcióra is igaz.

Egeszen agyalagyult hujesegeket is beleirt, pl.:

> This shouldn’t be a problem for those who have Microsoft DNS servers, but it can be problematic for non-Microsoft DNS servers. For example, my ISP manages my DNS entries. The ISP had no idea how to create the SRV records because it uses a Linux DNS server. That isn’t to say that the DNS entries won’t work with a Linux DNS server — but if someone else manages your DNS, you might have trouble getting the necessary DNS records created.

2x-es atolvasas utan sem tudtam kihamozni, mit akar kinyogni.
Talan azt, h szukseg van a megfelelo srv rekordok ismeretere? De akkor miert nem azt irja?

> Microsoft does not allow you to install software onto the Office 365 servers.

Huha, itt a vilagvege:)

Ugy altalaban blikkszaga van a cikknek:)

Én nem lennék vele ennyire szigorú.

Igaz, hogy elég népszerűsítő hangvételű, de - amennyire én meg tudom ítélni - elég pontos és nem elfogult, valamint olyan dolgokra hívja fel a figyelmet, amiket könnyű elfelejteni.

Simán el tudom képzelni, hogy egy DNS szolgáltató a webes felületén nem enged SRV rekordokat létrehozni...
De a másik sem ördögtől való: ha valaki újonc az Office365 világában, simán feltételezhetné, hogy a Microsoft enged 3rd party kódot telepíteni a szervereire...

Üdv,
Marci

> népszerűsítő hangvételű

Marmint minek a nepszerusitesere iranyulna? Nekem egy olyan cikknek tunik, mintha a ficko megporgette volna a lamerszamlalalot 10x es melle irt egy blog bejegyzest. Erre irtam, h agyalagyult.
Persze, siman elkepzelheto mind1, mint ahogy annyi marhasag az eletben, de alapveto dolgokat nem szokas kiemelni.

> Simán el tudom képzelni, hogy egy DNS szolgáltató a webes felületén nem enged SRV rekordokat létrehozni...

Mi koze ennek a linux-hoz, windows-hoz, vagy barmi mashoz ebben a formaban? De igazabol tovabbra is az a kerdes, h akkor miert nem ezt irja?
Mi, az olvasok csak talalgathatunk, h mire gondolt az iro, ill. celkozonseg vagy eltalalja, amire fel akarjak hivni a figyelmet, vagy nem. Marpedig ha ez nem jon at -> szaracikk:)

> De a másik sem ördögtől való: ha valaki újonc az Office365 világában, simán feltételezhetné, hogy a Microsoft enged 3rd party kódot telepíteni a szervereire...

Alapveto problemak vannak azzal a vezetovel, aki egy olyan embert vesz fel ill. jelol ki a feladatra, aki nincs tisztaban ezzel a tennyel az adott kontextusban es meg a migralas elott.

BTW az AD-s reszt sem ertem. Az MS cloudjat nem lehet szinkronizalni a lokalis user directory-bol?

Es tudni kell azt is, ami a dokumentaciokban nem hangzik el. Mi tul vagyunk egy ilyen projekten, es bizony egy csomo mindenrol hallgat az MS doksi. Egy ilyen infomorzsa hianya (vagy eldugottsaga) miatt ket napot allt egy ufelunk leveledzese. Na jo, a ket nap mar az MS support hulyesege volt, a feladatok ossze-vissza delegalasa miatt.

Azt mar csak halkan jegyzem meg, hogy botranyos, hogy az egyes supportosoknak otletuk sincs, mi a feladatkoruk, mit tehetnek meg es mit nem. Csak passzolgatjak a labdat, kozben meg all a rendszer.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A cikket (ami a blogjukban jelent meg, es aminek a PR is celja) a linkedin 'Archiving Professionals' group-ba kuldte be a joember, szinten massziv PR megfontolasokbol. Igy nem az a hangsulyos benne, hogy szerinte egy linuxos dns szerveren problemas egy srv rekord felvetele (nem az), hanem az a remelt asszociacio, hogy ha mar egy ilyen osszeszedett cikket tudtak csinalni, akkor biztos expertek a temaban...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Jó a felhő, amíg működik!

Augusztus 5 Hajnali 2 óra. Az MS adatközpontja Hollandiában elkezd nem elérhetővé válni. Reggel 8-ra az egész központ Hollandiában elérhetetlen, nincs mit szépíteni, site down! Az összes webservice-ünk, db-nk, virtuális gépünk off! 2 virtuális gépünk teljes HDD tartalma soha többé nem visszaállítható állapotba került! Olyan szintű filerendszer sérülések lettek rajta! Na erre a mai napig várom a bocsánatkérő e-mailt! Az anyagi kártérítésről már nem is beszélek!! Egyedi kiemelt SLA-t vállalt az MS mindenre!

lehet azert nem ad az ms karteritest, mert a virtualis gepek futottak, max 1-2 percet alltak. ja, hogy a filerendszer kiesett alola? arra nem vonatkozik az sla.

akar igy is hangozhatna az ms valasza. erdekelne a tortenet, ha le tudod/akarod irni. mit valaszoltak a kerdesekre, hogy mi lett a filerendszerrel, hol a backup es hasonlok?

Hol is érdekel, hogy szerinte futott a virtuális gép, ha maga az adatközpont az internet felől teljesen elérhetetlen ? Ami barátilag 8-9 órán keresztül tartott!

Mentés volt róla, azért tudtuk "gyorsan" újraéleszteni a gépet. A webservice, db problémát meg valahogy visszavarázsolták!

Mint minden nagy cég ők is kirakták a supportot Indiába. Azt tudtam, hogy a kínaiak agyhalottak, ha bármibe gondolkodni kéne, de ugyanez igaz az indiaiakra! Próbálkoztak mindennel, de szerintem azt se tudják mi az a Linux! A legszebb az volt, hogy javasolta, hogy a webservice-eket, meg a db-t tegyünk georedundánsá. Ezzel csak 1 baj van, mindent georedundánsá lehet tenni, kivéve ezeket :)
Maga a disk megpusztulás az oprendszereddel ezzel kezdődik:
https://social.msdn.microsoft.com/forums/azure/en-US/03982da2-17ca-4433…
Erre írta a kis "barátom", hogy ismert probléma, de nincs rá megoldás jelenleg! Azt még kiköpte, hogy csak Linux oprendszernél van ez így! Köszi B+

Minden áron a kern.log-ot akarta tőlem és nem értette meg, hogy semmilyen módon nem érem el a szervert ( ssh, ftp, stb.. ), bár az Azure dashboard azt mondja hogy up and running, de semmire nem reagál a gép!

Nos ezóta kicsit óvatosabban kezeljük a Felhő témát!