Vlákno názorů k článku Mnichovské kritice Linuxu chybí pádné argumenty od robert - no docela by mne zajimalo opravdu objektivni srovnani...

Schopný admin netvrdí že se systém "chová divně", ale analyzuje problém. Nástroje na to máte, jen je umět používat.

Ohledně zaplnění RAM: některé aplikace trpí na resource leaks. Takový resource leak byste měl být schopný najít, omlátit dodavateli o hlavu a donutit ho k opravě.

" Takový resource leak byste měl být schopný najít"
Mohli by ste to prosim trosku rozviest :-) ?

Pokud se stroj začne chovat vláčně, nejspíš má nějaký resource bottleneck: CPU, paměť nebo disk. Všechny tři věci můžete dobře monitorovat pomocí vestavěného Resource Monitoru. Snadno pak najdete proces, který žere jeden z těch třech zdrojů.
Pokud problém není vidět tady, může jít například o nesprávné zamykání DB, visící TCP spojení na klienty atd. Pochopitelně i tady existují nástroje, kterými zjistíte příčinu problému.

Nie pytam sa na nastroje, konkretne ma zaujima pamet. Resource monitor mi pise ze iexplorer.exe pid 8156 berie 207 780KB ? Su tam 4 udaje o RAM ktore nechapem co znamenaju :-) ale neva, zda sa ze explorer ako pisem tento komentar vzrastol na 213 500KB. Je to memory leak? Ten explorer je modelovy pripad, ale zaujima ma ako to ma chudak admin zistit ( a mozno tiez niekedy ja sam). (Uz je 218 076KB)

JavaScript bohužel umožňuje memory leaks. Můžete použít například sIEve. Ovšem oprava není na vás, ale na autorech webu. Přitom když si pustíte pár tabů Youtube a Facebooku, po čase vám sežerou GB paměti v každém browseru.
http://home.online.nl/jsrosman/sievehelp.htm

ale samozrejme :-D Explorer ma leak (keby len jeden) v implementacii cohokolvek ... a ten co to ma opravit je chudak web developer. Aby nahodou nepouzil volanie, ktore Explorer nezvlada bez leaku :-D
Ako by take weby vyzerali? Cisty text bez css, obrazkov a najlepsie aby sa zmestili na jednu obrazovku bez scrollu? :-D
Boze to je nazor...

Ale pridam moju skusenost. Dell blade server, 4GB ram, nejaky dual quadcore xeon. Jeho dina uloha bola exchange pre jednu jedinu domenu s 20 schrankami. Vysledok - 4 giga zozral len samotny exchange pri starte. Na dotaz u typka s certifikatom od ms ci to je normalne odpoved: jasne. 4 je minimum co to vie zozrat. Co je trosku na pocudovanie ked postfix spravujuci cez 200 domen s 2000 mailboxami zere 400MB ram a pusteny odkedy nabootovala masina: 290 dni :-D

Ale musim uznat ze to bezalo - mozno vdaka tomu ze sa to cele same resetovalo vzdy ked sa ms podarilo vyprodukovat nove bugy a naisntalovat ich cez windows update :-D

JavaScript umožňuje resource leaks, to je bohužel fakt. Weboví vývojáři jsou často patlalové, kteří jsou horko těžko schopní svoji "aplikaci" rozhodit, natož aby se zabývali nějakými resource leaks. Ještě k tomu že je to věc MSIE: proč tedy ty samé problémy vidím ve Firefoxu a Google Chrome?

Ad paměť u MS Exchange vs Postfixu - Postfix je hloupý MTA, nepodporuje kalendáře, veřejné složky, plánování zdrojů (zasedačky apod), workflow, fulltext indexing, webový interface a nejspíš ani push technologie. Srovnávejte srovnatelné. Navíc velikost paměti u MS Exchange lze konfigurovat; by default jsou hodnoty poměrně velké, protože se očekává nasazení ve velkých firmách.

Tj, rozesrana databaze exchange je nocni mura ... to ani spravovat nema smysl.

Když ten argument vezmu vážně :), tak samozřejmě máte možnost spousty konfigurace, které s tím dokáže něco udělat.

Jiste, trebas nahradi nefunkcni IIS za fungujici apache, jenze do se dela dost blbe, kdyz dodavatel dodava svuj vytvor pro IIS.

Jenže problém zřejmě nebude v IIS, ale ve výtvoru toho dodavatele. To elegantně přehlížíte.

Loliku, apache mi neschodi system, a to tak ze nikdy. IIS naprosto spolehlive sejme widle.

Jiříčku, když je to tak spolehlivé, jistě nám tu popíšeš způsob, jak problém reprodukovat.

cize sa tym popiera tak casto glorifikovana vyhoda windowsu oproti linuxu - windows ide sam a linux musis tak velmi konfigurovat :-D

Ono to také v praxi nebývá potřeba.

Ty v té práci jsi 24/7, že máš čas na analýzy problémů woken? Proč by měl ztrácet svůj čas analyzováním problémů způsobeným Macroshitem? Neměl by omlátit widle dodavateli o hlavu a donutit ho k opravě?
Kromě toho neznám admina, co by se s něčím jebal pořád dokola a marně, když cesta nejmenšího odporu je noční restart.

Jenže ty problémy bývají způsobené převážně aplikacemi, ne OS. A proč byste měl ztrácet čas řešením problémů? Protože to je váš job.

Ad neznám admina, co by se s něčím jebal pořád dokola a marně, když cesta nejmenšího odporu je noční restart - dobrých adminů je bohužel málo.

Totéž co s open source aplikacemi: kontaktovat dodavatele.

Tož co s komerčními od MS? Přečtěte si licenční ujednání, v němž jste byli již předem ujištěni, že MS nenese za nic odpovědnost.

Jakou podporu si koupíte, takovou máte. V základu samozřejmě žádné smluvní pokuty nejsou, odpovědnost MS za následné ztráty je nulová, a pokud zákon vylučuje nulovou odpovědnost za následné ztráty, tak je omezena na pořizovací hodnotu licence.

LOL mě už to taky napadlo, on je totiž výborný teoretik, vše mu funguje, verze office jsou naprosto kompatibilní, lokální síť a sdílení běhá vždy bez problémů, nikdy se mu nestalo, že by widle nenastartovaly ani do nouzového režimu... ale když dojde na praxi, je to bída. No a když něco někomu "náhodou" nefunguje, tak je to pochopitelně jen a jen jeho chyba, je špatný admin, který by měl hledat cizí memory leaky... no sranda :-)

To s tím dodavatelem špatně jednáte. Navíc pokud vám dodavatel zmrší aplikaci, není to problém platformy, a není v tom ani větší rozdíl v platformách - aplikace pak nebude fungovat korektně na žádné platformě.

Samozřejmě jsem systémy s Windows (a nejen s nimi) administroval.

Loliku, dodavatel je gold ci kyho vyra partner M$, a ten M$ ho stejnak posla tak maximalne do <>ce, kdyz mu dodavatel nareportuje, ze v jeho widlich je bug jak krava, a ze jim jejich appka delana presne podle dokumentace pada.

Takze zcela zjevne vis naprosto kulovy o tom, jak veci fungujou.

Jeníčku, kdybyste byl programátor, tak byste věděl, že se pro Windows píše velmi dobře, API má kvalitní dokumentaci a je má minimum bugů. Programátoři-patlalové samozřejmě mají problémy, ale ti je mají všude.

Ad zcela zjevne vis naprosto kulovy o tom, jak veci fungujou - OK, jistě se nám svěříte s konkrétním příkladem toho bugu. Které API, v jaké situaci? Vy hodně plácáte, a píšete zatraceně málo konkrétních informací - protože většinou nerozumíte tomu o čem mluvíte.

jo loliku, to uzasny psani pro widle jsem mel tu cest ... videt na vlastni kukadla. Vase vlastni visualko se nebylo schopny syncnout s tim vasim kramem (ted nevim jak se to jmenuje, ale je to neco na tema svn).

Nebo dalsi uzasna vec, u toho dokonce vim, ze se tomu rika konektor ... fakt bomba, dodavatel zmeni query, a musi ho celej smazat a zalozit novej, protoze kdyz jen vymeni, byt nepatrnou a zcela nepodstatnou cast ve where, tak se to cely rozsype, klidne si to zalozi novy, zcela neexistujici pole (na tema pole vs pole01) a vsechno se pak pochopitelne rozesere, protoze vsude v kodu se cte pole, ve kterym nic neni.

Taky to zjevne neumi fungovat bez napojeni do databaze, coz je uzasny, kdyz clovek potrebuje neco zmenit, a nema zrovna moznost se k ni pripojit ...

Aha. Takže jste jednou viděl synchronizaci VS s TFS, a jednou vám podle toho popisu asi někdo ukázal nějaký nástroj pro vizuálního návrh, se kterým neuměl zacházet (a který se v používá leda v triviálních aplikacích). Jo, to už je z vás skoro vývojář :D. Samozřejmě o žádném bugu, o kterém jste psal, nevíte vůbec nic, a jen plácáte. Proč mě to nepřekvapuje?

Drahý čtyřnožče, v takovém případě je na místě dát podpoře dodavatele vzdálený přístup pod dohledem, a nechat je problém řešit. Ať si to vyříkají se svým dodavatelem.

BTW pokud by dodavatel dodal podobně zmršenou aplikaci pro Linux/Apache, byla by situace nějak odlišná? V principu to totiž podle všeho není problém OS ani webového serveru, ale konkrétní aplikace, a hlavně komunikace s dodavateli.

Jiste, sem zvedav jak budou komunikovat s dodavatelem 95% toho reseni - tedy s M$. Ten je samo odkaze na to, ze system uz nepodporuje + ze neruci vubec za nic.

MS tu aplikaci samozřejmě nepodporuje, musíte mluvit s dodavatelem. Předpokládám že když vám nejde aplikace postavená nad DB Oracle, tak také na ní nechcete podporu od Oracle nebo výrobce OS. Pokud to vidíte jinak, vidíte to špatně.

Samozřejmě že se problém dá vyřešit. Vy to zvládnete pro Apache, já to zvládnu pro IIS, a náš drahý kolega... zvládne restartovat server. A v tom je ten rozdíl.

Kozec snad není slovensky kozel? :)

Slovensky kozel je cap :-)

ctvornozec ses preto, lebo lolik po slovensky nevladze .... ;D

Podobne jako nechape, ze s vadnym IIS a widlema proste neudelas nic. Ani kdybys cirou nahodou mel verzi "podporovanou", nebylo by ti to platny vic, nez mrtvymu zimnik.

Mimochodem, pamatuju si (kuprikladu) to, jak sme kdysi resili, proc nenastartujou zcela ciste nainstalovany w98 ... a samo, jakozto "parner" M$ sme se teda obratili na ne. Tahali z nas SN a nakonec nam rekli, ze se mame obratit na dodavatele PC ... coz sme byli mi ... lol. Vysledek? Samo zjistenej bez M$ ... Mno w98 proste nenastartovali s vic nez 512MB ram. Musels je nastartovat s min, zakazat jim pouzivat vic, a pak si tam moh tu pamet navic (ktera tam byla uplne zbytecne) pridat. Ostatne, jejich 32bit w7 neumej vic nez cca 3,5GB dodnes. Na to si musis naisntalovat externi appku, pripadne widle ohackovat ...

'lebo lolik po slovensky nevladze .... '

To je nějaká speciální slovenština z Varšavy ne? ;)

S vadnými Windows a IIS samozřejmě můžete udělat spoustu věcí, pokud máte koupený support. Navíc jste popisoval problém, který byl podle všeho způsobený aplikací. BTW co uděláte s vadným Linuxem a Apache? :)

Pokud máte OEM licenci Windows, podporu poskytuje dodavatel systému. Když si koupíte díky a k nim OEM licenci, jste svým vlastním dodavatelem, a je to na vás. Máte přístup k Knowledge Base.

Vadný linux a Apache? Co si pod tím mám představit?

"Pokud máte OEM licenci Windows..."

Jasně vám psal, ze support M$ doporučuje restart widlí, tak sem nezatahujte OEM licence.

To se zeptejte kolegy Jiříčka, který tu psal cosi o vadných Windows a IIS.

Ad Jasně vám psal, ze support M$ doporučuje restart widlí, tak sem nezatahujte OEM licence - zřejmě se vám nějak pomotaly thready diskuse?

Nikolivek, to ty to mas na mozku uz totalny vymatlany.

"To se zeptejte kolegy Jiříčka, který tu psal cosi o vadných Windows a IIS."

Takže nevíte, jen trollujete.

Mohl jste si všimnout, že trolluje Jiříček. O "vadných Windows a IIS" nenapsal jediný detail. A protože vím že detaily nenapíše, ježto neví o čem mluví, tak se ho ptám, jak by řešil "vadný Linux a Apache".

Jedinej kdo tu vi lautr howno ses ty loliku, protoze widle zasadne zadny detaily nesdelujou, tak maximalne pindy o neznamy chybe. Coz ostatne presne odpovida tem srackam ktery tu neustale dokola blejes.

Jde o troubleshooting aplikace, ne IIS. A vzdálená podpora je běžně používaný postup, zvlášť pokud máte dodavatele někde v Německu. Pochopitelně je dodavatel pod dohledem zákazníka, zvlášť pokud jde o nějaký citlivý systém.

Loliku, prace admina je udrzet veci v chodu, ne zjistovat proc nefungujou widle. A vazne nevim, proc bych mel stravit mesic hledanim problemu, kdyz ho stejne NIKDO nevyresi. Ale jo, muzu si nahodi nejake hexaeditor a zacit opravovat dllka.

Proto se zcela zasadne widle NIKDY nespravujou, protoze vsichni davno vedi, ze i kdyz venujou disitky hodin casu na analyzu problemu, tak jedinej vysledek bude, ze "o teto chybe neexistuji dalsi informace". Proto se widle rovnou reinstalujou, protoze je to asi tak o 10 radu levnejsi a efektivnejsi.

widli log:

Stav služby Multimedia Class Scheduler byl změněn na: running
Stav služby Multimedia Class Scheduler byl změněn na: stopped
Stav služby WinHTTP Web Proxy Auto-Discovery Service byl změněn na: running
Stav služby Windows Modules Installer byl změněn na: running
Režim spuštění služby Windows Modules Installer byl změněn z demand start na auto start.
Režim spuštění služby Windows Modules Installer byl změněn z auto start na demand start.

To sou udaloste, co? ... Tehle sracek je plnej log.

Ale muzem samo i "zajimavejsi" - oznacene jako error - (celkem standarni denne pouzivanej desktop)

Neočekávaná chyba. Kód chyby: 490@01010004

Od zacatku roku cca kolem tisicovky logu oznacenych jako error ... a to je jeste prdlajs, nasel bych i takovy stroje, kde jich budou desitky tisic ... presto je jejich uzivatele celkem normalne pouzivaj ... proste u M$ je error v logu celkem nezajimava normalni vec. Ostatne, parkrat sem se sel podivat do errorlogu ciste nainstalenych widli, chyby tam byly vzdy.

1. Když si projdete logy nějakého unixového systému, najdete podobné hlášky. Pokud chcete vidět jen chyby, naučte se v Event Vieweru používat filtry.
2. Na Unixech často dostanete spoustu chod nijak neovlivňujících chyb i když si jen pustíte GUI aplikaci z terminálu. Někdy si to zkuste.

1. Mě ty hlášky typu "Stav služby Multimedia Class Scheduler byl změněn na: running" nepřijdou až tak nesrozumitelné :)

2. Pokud spustím GUI aplikaci z terminálu a začne na mě házet chyby, tak je to špatně. Samozřejmě ve /var/log najdete také spoust chyb, které nijak neovlivňují provoz.

1. Ona je to také informace o startu (BTW nikoliv zastavení) servisu, ne o důvodu toho zastavení. V detailech jistě najdete víc informací, například ID volajícího procesu.

2. Já tam těch chyb vždycky našel požehnaně. Tedy na desktopu - na servery u nás Unixy nesmí :)

Ono to "našel" už bude před spoustou let, že?

Právě že viděl, a proto je u nás nemáme. A není to nijak výjimečné. Projděte si firemní serverovny - Unixy jsou od devadesátých let na ústupu, dneska abyste je hledal s lupou.

Pracoval jsem se systémy DEC, Sun, HP a IBM. Samozřejmě jsem přišel do styku i s Linuxem - ve srovnání s dříve jmenovanými systémy je jeho kvalita dost tristní. Další detaily o své osobě si s dovolením nechám pro sebe.

Linux se používá primárně na internetovou infrastrukturu, a to primárně díky nulovým pořizovacím nákladům. Uvnitř firemních serveroven je situace značně odlišná.

LOL hotovej Brouk Pytlík :-D

Jistě, není nad argumentum ad hominem. Školení demagogie je pro uživatele Linuxu povinné, nebo jste ho absolvoval navíc? :)

Tak důležité je, že to umíte napsat přímo latinsky ;-)

Pokud jde o školení demagogie, tak vaši úrovně jsem teda nedosáhnul a pochybuji, že se mi to kdy podaří.

Event ID není pořadové číslo události v logu. Je to ID (typu) události, v tomto případě EVENT_SERVICE_CRAS­H.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363632(v=vs.85).aspx
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=7031&EvtSrc=Service+Control+Manager

Vyjma toho byste měl v event. logu najít i vlastní pád servisu, který vám může něco říct. Vyjma toho si můžete zapnout logování spooleru. V druhém linku zjistíte i jak použít debugger.
http://blogs.technet.com/b/askperf/archive/2008/08/12/two-minute-drill-enabling-print-queue-logging.aspx
http://social.technet.microsoft.com/wiki/contents/articles/13308.troubleshooting-windows-server-2012-printing.aspx

Samozřejmě to že jde o "vhodně" formátované PDF zjistíte rychleji metodou pokus-omyl. Drivery od HP jsou obecně dost tragické. Doporučuji instalovat ty jejich minidrivery, což je v podstatě DLL s parametry pro driver od MS, kde to HP nezmršili vlastním kódem.

Takže event ID není ID, ale typ. Jo, to se to pak ladí, když MS ani nezná terminologii :-)

Hele loliku, a co ma spolecnyho driver s tim, ze zbuchne spooler? Zeby zhola ... NIC?

Koukněte se někdy, Jaroušku, jak se používají knihovny, a co se stane s aplikací, když dojde k chybě v knihovně.

Koukněte se na to, jak to dělá CUPS. Pokud máte špatný ovladač tiskárny nebo backend, rozhodně nepadá, protože je to spooler a ne všeumějící aplikace, takže sám umí jenom přehazovat data a spouštět jiné příkazy ;-)

"jak se používají knihovny"

No asi blbě, když shodí spooler :-D

Až napíšete nějakou aplikaci používající knihovnu, nebo alespoň budete vědět o čem je řeč, přijďte si o tom znovu popovídat. OK?

Loliku, kdyz pisu aplikaci, tak zavolam knihovnu, a ta mi vrati nebo nevrati nejaky vysledek, aplikace podle toho bud vrati nebo nevrati nejaky chybovy hlaseni, ale rozhodne to neni duvod k tomu, aby zbuchla. Samozrejme pokud to napise nejakej dobytek od M$, tak se appka slozi, protoze se nepredpoklada, ze by trebas knihovna nevratila nic ... ze.

Drahý Jiříčku, zkuste si představit, že v té knihovně dojde k výjimce. Například hrábne do paměti mimo adresní prostor aplikace. Co se pak stane? Protože je to knihovna, kód běží v kontextu aplikace, která ji používá. Takže spadne *ta aplikace*.

To je samozřejmě jen jeden ze scénářů. Pokud má například knihovna vrátí nějaký pointer, ten směřuje někam mimo, a aplikace se pokusí ho následovat, tak také spade. To se stane například pokud se volání knihovny úspěšně vrátí, s tím že mimo jiné vytvořila novou instanci objektu, ale pointer na ten objekt je null.

Ono to skoro vypadá, že vaše znalosti principů OS jsou stejně slabé, jako vaše znalosti prakticky čehokoliv jiného, k čemu se snažíte vyjadřovat.

Pak je spíš otázka, jestli u takové služby vůbec používat kód třetích stran jako knihovny, nota bene když se to ani neumí z pádu zotavit. Pokud knihovna v Apachi hrábne mimo adresní prostor, rozhodně se nezhroutí celý Apache.

Mohl jste si všimnout, že se servis automaticky restartoval, takže došlo k zotavení.

"... a po restarte sa pokusil vytlacit ten isty dokument a zrutil sa znova :)"

LOL to je fakt psycho :-D

Vážně? Já myslel, že se dokument nebude zpracovávat znovu. BTW restart servisu proběhne dvakrát, pak už se nerestartuje.

Rekl velky lol a tutiz to tak bylo, je a bude az do skonani sveta ...

Normalni system nedovoli knihovne hrabat mimo prideleny adresni prostor loliku. Nehlede na to, ze normlani sytem se nehrouti kvuli jakykoli knihovne.

Jeronýmku, copak se stane, když se knihovna pokusí hrabat mimo přidělený adresní prostor? OS ji to nedovolí, a "dycinky" spadne. Víme?

Ad normlani sytem se nehrouti kvuli jakykoli knihovne - systém většinou ne (driver je svým způsobem také knihovna), ale proces ano.

"Až napíšete nějakou aplikaci používající knihovnu, nebo alespoň budete vědět o čem je řeč, přijďte si o tom znovu popovídat. OK?"

OK, aplikace používající knihovny jsem psal už před 20 lety a vím o co jde, takže jsem zpět.

loliku, kdyz mam v tuxovi vadnej kernel modul, tak mi nespadne celej system, ale odstreli ten modul, a jeste k tomu pekne poctive zaloguje, co a proc se stalo. Pokud mam vadnej modul k tiskarne, tak je to spooleru uplne jedno, protoze ten snim nema nic spolecnyho.

Chyby s číselným kódem jsou dost neobvyklé. Pokud na ně dojde, můžete buď googlit, nebo se kouknout do seznamu chybových kódů. Doporučuji tu druhou možnost. Plus si můžete stáhnout utilitu err.exe, která vám na chybový kód vrátí hlášku.
http://msdn.microsoft.com/en-us/library/cc231199.aspx

Loliku, na tuxovi jednak nema ZADNE hlasky typu error (ani jednu jedinou), dokonce ani zadnou typu warning, druhak mi loguje jen presne to, co logovat chci. Zadny nicnerikajici plky.

Protoze kdyz se na tuxovi objevi error (nebo i ten warning) tak se narozdil od widli da vyresit. Mimochodem, citace podpory M$ ... "tyhle chyby ignorujte".

Tj, zlaty doby 8mibitu ... to appka/system vratila hlasku error 4897 ... a clovek si to snadno nasel.

Jaroušku, problém bude spíš v tom, že neumíte základy troubleshootingu. Pro méně schopné adminy opravu může být jednodušší dokola restartovat a reinstalovat, protože na víc nemají. Otázkou je, jestli by se pak měli nazývat administrátory. Takoví totiž dělají špatné jméno sobě i své profesi.

Naopak loliku, schopnej admin vyhodnocuje casovou narocnost operaci, a protoze vi, ze casova nacocnost opravy widlich menstruaci se blizi nekonecnu, tak se tim nezabyva. Jeho chlebodarce by ho totzi brzo vykop, kdyby spravoval 30dnu z mesice PC jeho ucetni, protoze analyzuje v cem je problem ...

Vis loliku, krome zmeny distra sem tuxe nikdy nereinstaloval, ani jednou, a vis ty proc? Protoze casova narocnost vyreseni problemu, se velmi blizi nule. Jeste se mi nestalo, ze bych behem par minut nenasel pricinu i lecivo. A co vic, tux se nereozesere sam od sebe, kdyz se neco stane, tak vyhradne pri nejakych zasazich => je na to cas. Ne jako u widli, ktery vyhnijou proste casem.

Windows samozřejmě nevyhnívají časem samy. To myslíte že je to nějaká magie? Jsou to aplikace, data a nastavení. Když víte co děláte, rychle najdete problém i řešení. Když nevíte, můžete na to měsíc čumět jak husa do flašky.

Jiste loliku, proto widle po 1/2roce az roce startujou 10x dyl, proto casto uz ani nenastartujou .. presto ze na nich jsou (pro jistotu) zakazany i M$ aktualizace, a tudiz na to nikdo ani nesah. A proto ma registr klidne stovky MB ...

Jendo, tyhle pohádky běžte povídat dětem, třeba vám to dokonce uvěří.

Tohle je na windowsech naprosto běžný jev, který znají všichni uživatelé. Než jsem likvidoval poslední windows na domácím počítači (to už jsem tam měl dual boot s linuxem), tak startovaly cca půl hodiny. V praxi jsem to dělal tak, že jsem zavolal děckám domů před odchodem z práce, ony to zaply, a než jsem se dostal domů, tak to bylo jakžtakž funkční.
Ona nenávist MS vůči linuxu je vcelku pochopitelná: plnohodnotný a funkční systém je dosti návykový a kdo si na něj zvykne, tak se k produktům od MS vrací jen s odporem, protože je zvyklý, že systém a programy fungují, a to svižně.

Že to není problém Windows, ale tvůj to tě nenapadlo? Nainstaloval sis tam (nebo děcka ti tam nainstalovala) tunu kdovíjakého balastu, co se natahuje při startu a pak se divíš. Moje zkušenost je taková, že se start Windows časem sice opravdu zpomaluje, ale je to tak v řádu vteřin. Startovat Windows na rozumném hardwaru dýl jak minutu jsem ještě neviděl. Nehledě k tomu, že sám počítáč už roky jenom uspávám, takže mi 'startuje' tak 5 vteřin max.
Ona nenávist Linuxáků vůči Microsoftu je vcelku pochopitelná: ono dívat se jak si lidi vyzkoušejí Linux a ještě moc rádi se vracejí k byť nedokonalým, ale pořád o dost použitelnějším Windows musí pro ně být dost frustrující ;)

Nejsem linuxák (já vlastně ani nevím, co si pod tím mám představit, pokud kritiku M$, tak linuxák jsem), ale mně spíš přijde frustrovaný někdo, kdo na web převážně o linuxu chodí dlouhé roky plácat nesmysly o tom, jak jsou widle dokonale funkční a bezchybný systém. Taková nenávist stále více se prosazujících OSS technologií musí být opravdu frustrující ;-)

BTW už několikrát jsem se ptal a zatím mi nikdo neodpověděl, tak odpovíš třeba ty: co z toho máte, že lobujete za cizí zahraniční megakorporaci a její proprietární produkty? A co máte z toho, že se snažíte (kolikrát velice trapně) shazovat lidi, kterým se to nelíbí, nechtějí být závislí na jedné konkrétní firmě a nějak proti tomu bojují? Připadáte si drsně, cool, nebo se považujete za hrdiny?

Já za žádnou zahraniční megakorporaci rozhodně nelobuji, já se sem chodím vysloveně bavit, v okamžiku kdy se objevily zprávy o tom Mnichově mi bylo hned jasné, že se tu zase strhne nádherná diskuse, a měl jsem pravdu. Takové perly co sem někteří místní borci házejí, to je prostě paráda. Aby bylo jasno já proti Linuxu nic nemám, sám Linux používám, na server je Debian jasná volba, a dlouhé roky jsem jej používal i na desktopu. Akorát mne mrzí že někteří zastánci Linuxu tu prostě otevřeně lžou a nebo blábolí naprosté nesmyly, to se pak někdy ozvu.

Já jsem si žádných vyložených lží z řad zastánců linuxu nevšiml. Možná jsem nějakou přehlédl, ale to znamená, že jich zas tak moc nebude. Oproti tomu "opačná strana tábora" je pravdomluvnost a nedemagogičnost sama :-)

Nevšiml? To asi přehlížíš většinu příspěvků od j. Stačí se podívat o kousíček níže kde reaguje na mně - nejprve začne ironickým oslovením (zřejmě aby ukázal světu jaký je borec) pak s naprostým klidem lže o tom, že se bavíme o serverech, přičemž diskuse je desktopech, a na závěr si neodpustí aspoň jednu zkomoleninu MS, opět aby ukázal světu jaký je to borec a krutopřísežný linuxák :) A takhle tady bohužel vypadá většina jeho příspěvků.

No, ona ale řeč opravdu o serverech celou dobu byla, to až A.S. Pergill a ty jste začali mluvit o desktopech ;-)

Hele, sice se j vyjadřuje trošku květnatě, ale tomu, co říká, klidně budu věřit na rozdíl od toho, co zde prezentuje jistý Lael, u kterého je chyba VŽDY jinde, než u produktů M$. Buďto je zmršená aplikace (pozor! zmršená aplikace rozhodně nemůže být od M$, v tom případě je chyba stoprocentně někde jinde), nebo je problém se sítí, nebo je neschopný admin, nebo tisíc dalších věcí. Já se v IT pohybuji profesionálně již přes čtvrt století a za tu dobu jsem něco viděl a zažil, a že to byly často neuvěřitelné věci.

Jinak no offence ;-)

Také jsem v IT řadu let, a také jsem viděl těžko uvěřitelné věci . BTW zpočátku často na Unixech, než jsem zjistil, že za desetinovou cenu může mít člověk PC server :). A protože jsem toho spoustu viděl, odmítám například šmahem vinit IIS, když s nejvyšší pravděpodobností někdo zmršil aplikaci, která na něm běží.

Kolega "j" se vyjadřuje jako kdyby se narodil v ghetu. To ale není nic proti tomu, jaké neznalosti v diskusích veřejně ukazuje.

Kolega "j" se vyjadřuje jako kdyby se narodil v ghetu.

Asi tak, "květnatě" je opravdu zbytečně nadnesený termín.

Máme na ústavu v učebách windows na zcela nových počítačích, nemáme k nim administrátorská práva, takže tam nemůžeme "instalovat žádný balast" a přesto naskakují 5 - 10 minut a občas i zatuhnou. Proti linuxu naprosté utrpení.
Jinak registry bobtnají každým zapnutím počítače a každou akcí na něm. Přitom se natahují celé do paměti, takže jí ukusují stále víc a to natahování nakonec přejde na swapování systému, když už volná paměť nestačí.
K návratu k windows vede prakticky vždy (s jinou příčinou jsem se nikdy nesetkal) záměrná nekompatibilita MS formátů s jejich standardy. Případně existence win only formátů a technologií typu Silverlight.

A já jsem viděl takové hromady učeben a kanceláří kde měli hromady počítačů s Windows, které nabíhaly normálně do té jedné minuty a nezatuhávaly. Možná to bude tím, že někde prostě mají šikovného admina a někde ne.

Jiste ... proto kdyz si pustim z win 7 RDPcko, tak mi KAZDA JEDNA sesna sezere 300MB RAM? Takze kdyz potrebuju bejt pripojenej na 5 stroju, tak jen na to potrebuju 1,5GB? Jasne, za to si urcite muzu sam ... stejne jako za to, ze jakejsi proces svchost bezi asi tak 30x, sezere dalsi GB ram, a 50% CPU ...

Jop, vazne by me zajimalo, jak sikovnej admin resi to, ze si koupil za nehorazny prachy licenci na terminalserver, a ten ma jen po prvnim prihlaseni vsech uzivatelu registry velky 2GB ... a rostou a rostou ...

'ze jakejsi proces svchost bezi asi tak 30x, sezere dalsi GB ram, a 50% CPU'

Ty vážně netušíš ani co je svchost.exe a jak s ním připadně zatočit?

Aaaa dalsi plkalista, hosicku, bavime se tu o serverech, muzu ti predvist widle, ktery startujou 20 minut. Proc? No protoze je to uzasny M$ system. Nj, asi mame levnej HW, stalo to jen 5M ...

Lžeš, bavíme se tu o desktopech.

Tak zde je konkretni problem, ktery pocituji snad 5 let: XP pri poskytnuti vzdalene plochy zmeni power management settings z never/never/never na uspani po nahodne dobe. Takze pokud prestanu delat na RDP nebo se odpojim, stroj usne.

A co navic, kdyz zmenim volby zpet na never/never/never tak to nejde ulozit, pry chyba "Power policy manager unable to set policy: Indicates two revision levels are incompatible". Jde to jen ulozit pod novym nazvem, takze mam profily never1, never2, ... az kolem dvaceti nez to pak promazu.

Ted se divam, ze ty starsi profily ktere byly ulozeny jako never, maji v sobe nahodne data...

A reseni? Neni. Duvod? Neznamy.

http://www.textndata.com/forums/power-management-changed-when-remote-93682.html

Praktikuji toto:

WORKAROUND: Immediately on establishing the remote connection, open the power properties dialog and if they have changed, set them back to "never" (hibernate or go to standby) FROM THE REMOTE MACHINE. Now you can stay connected all day. If you forget that step, as I do once in awhile, you can lose the connection until you can get back to the remote machine and bring it back to life.

Ale nepovazuji to za reseni. Zrejme MS si o tom mysli neco jineho.

Tohle dává technologii Remote Desktop Connection úplně nový rozměr :-)

Ono RDpcko na widlich ma jeste dalsi uzasne nalezitosti. Konkretne mam trebas grafarnu (celkem jedno jestli NV nebo ATI), a kdyz se pripojim pres RDP, tak pro system neexistuje => nelze na ni spustit nejen zobrazovani (to bych jeste bych shopen pochopit, i kdyz nevim proc), ale nelze spustit ani zadny vypocet. System totiz zadne GPU nema.

Tuhle ficuru muzem povysit tak, ze pokud se ve widlich spousti neco, co s grafarnou nejak pracuje, je treba se nejdrive prihlasit lokalne, protoze jinak ta aplikace nenastartuje. Pokud uz bezi, tak kupodivu zustane bezet i po naslednem RDP konektu, ale samozrejme se nesmi ukoncit.

Totez samozrejme plati pro zvuk a zvukove karty, jakmile se clovek pripoji vzdalene, prestavaji pro system existovat. Tudozi pokud by nekdo zil v naivni predstave, ze si vzdalene na vzdalene zobrazovadlo pusti nejakou prezentaci (vcetne zvuku), tak to je pod widlema proste dokonale nerealizovatelne.

Boha. Když máte terminálový server, tak vzdálený uživatel samozřejmě nemůže používat zvukovou nebo grafickou kartu toho serveru. Pokud jde o výpočty, tam autor aplikace nemá používat shadery, protože ze servisu nebo Remote Desktop session nemá přístup ke grafické kartě serveru. Místo toho má používat DirectCompute/C++ AMP.

A pan je telepat ... co to meles o terminalovym serveru ty mamlase? Mam stroj kterej ma neco pocitat a potrebuju ho nejak adminovat ... nemluve o tom, ze na tuxovi to zcela normalne a presne dle ocekavani ... funguje.

Ještě jednou pro méně chápavé chlapce, co si hrají na adminy. RDP vytváří více sessions, a ty jsou pochopitelně izolované, takže nemají mít přístup ke zvukové ani grafické kartě serveru.

Jinými slovy vám někdo napsal aplikaci tak, že používá zdroje, které v terminálové session (ano, RDP) nejsou k dispozici. Pokud to nechápete, tak vzdejte IT, a jděte třeba smažit hamburgery. Prý je to méně intelektuálně náročné, a časem můžete povýšit třeba na vedoucího smažiče hranolek.

Nj, tady nekdo neumi napsat system, a podobni meneceni jedinci to jeste oslavujou. Loliku, kdyz se k systemu prihlasim jako admin, tak sem jeho BUH. A Buh smi VSECHNO. Pokud to nechapes, tak navsitch Dr. Chocholouska, bude z tebe mit radost, povesi si te na zed hned vedle slavne tarasnice.

On totiz kdyz nekdo provozuje nejaky HW, tak (pro M$ samo velke prekvapeni) proto, aby na tom HW neco bezelo. A pokud na tom HW nic behat nemuze, protoze nejakej trotl vymyslel, ze se to musi spoustet vyhradne lokalne, tak je proste takovej system zcela nepouzitelnej.

Mimochodem, loliku, presne tohle je duvod, proc v oblasti vykonu a stroju za mililardy $ po widlich ani vidu ani slechu. On totiz bezne vedec vyrazi na let pres 1/2 zemekoule, aby ci moh spustit svuj vypocet z lokalni konzole.

BTW: Uz ste se v M$ naucili, co to znamena need?

Jeníku, přečtěte si tohle. Třeba vám to rozšíří obzory.
http://www.root.cz/clanky/mnichovske-kritice-linuxu-chybi-padne-argumenty/nazory/511753/

Administrátor samozřejmě není bůh - jen by se tak někteří rádi viděli :). Existují naopak velmi dobré důvody mít například jen administrátora uživatelských účtů a podobné omezené administrační role.

Ad nejakej trotl vymyslel, ze se to musi spoustet vyhradne lokalne - ten trotl je autor aplikace. Jak jsem opakovaně psal, takovéhle aplikace mají jet přes DirectCompute/C++ AMP. Jinak je to totiž nebezpečné.

Nepracuji v MS, ale připadá mi, že slovo need chápou. A co vy, už jste si nastudoval alespoň ty compatibility options ve Wordu? :)

Jenže ono to nejde, ani když se připojí vzdáleně na svůj domácí počítač. Na Linuxu je dost jednoduché nastavit, jestli má uživatel přístup na zvukovku či grafickou kartu nebo ne, a tohle nastavení platí jak pro lokální, tak pro vzdálený přístup.

Jo, nejde to. Remote Desktop je postavený tak aby izoloval uživatelské sessions, i pokud přistupuje jediný uživatel. Ono když sessions neizolujete, má to dost závažné bezpečnostní důsledky (vizte třeba odposlech X11 events). Pro scénáře jako výpočty na GPU se používá DirectCompute/C++ AMP, v interaktivních aplikacích i servisech. Pokud spustíte v RDP session řekněme OpenGL aplikaci, která něco počítá s použitím shaderů, tak samozřejmě počítat nebude, protože nevidí grafickou kartu serveru.

Pokud se uživatel přihlásí lokálně a následně se k této session připojí přes RDP, žádnou novou izolovanou session to nevytvoří, jen se to začne tvářit, že grafická karta najednou není.

Nevím, jaké odposlechy X11 events máte na mysli, v Linuxu jsou uživatelské session také od sebe izolované, ale k hardware mají takový přístup, jaký jim dávají jejich práva, Linux se netváří, že tam žádný není.

Sessions mají vždy izolaci. Aplikace A ze session 1 nemůže posílat window mesages aplikaci B běžící v session 2. Když si vytvoříte session, můžete se k ní připojit z jiného terminálu - pochopitelně grafická karta zmizí.

Ohledně session isolation doporučuji tohle:
http://theinvisiblethings.blogspot.cz/2011/04/linux-security-circus-on-gui-isolation.html

Pokud jde o OpenGL, tak tam není problém získat obsah obrazovky. Vzdálený uživatel by získal možnost kreslit po obrazovce serveru a koukat na ni, což je z hlediska bezpečnosti průšvih. Je pěkné, že v daném scénáři uživatel jenom vytvoří shader, kterým něco spočítá, ale bezpečnostní díra je to tak jako tak. Proto MS doporučuje DirectCompute/C++ AMP.

Loliku o widlich a bezpecnosti radsi nemluv, to te radi na inteligencni uroven kymacejiciho se klacku.

Jakze, ono existuje neco jako rainbow tables? Coze? Ono se da widli heslo ziskat behem par vterin?

A máte také něco k diskutovanému tématu? Nebo vás zastrašily výrazy jako session a DirectCompute, a tak jste od tématu radši zdrhnul?

Jo, Rainbow Tables samozřejmě existují, a netýká se to jen Windows. BTW jak dostanete hash hesla z Windows během pár vteřin?

loliku, ja nepotrebuju z widli dostavat hash, ja z nich dostanu to heslo, staci kdyz si nastartuju ophcrack.

Jarošku, když máte práva admina na daném stroji, je celkem zbytečné z něj tahat hesla. Admin má možnost heslo uživatele prostě změnit, víme?

loliku, proc by ho admin menil, kdyz se na toho usera muze prihlasit, a trebas jeho jmenem poslat reditele dohajzlu. Pripadne to ani nemusi byt admin, staci kdyz to je kolemjdouci, ze. Protoze na to abych precet ty hesla vubec nepotrebuju startovat ty widle.

Tak si na Linuxu uděláte zálohu hashe hesla, změníte heslo, pošlete email a obnovíte hash hesla. Jedna ze zásad počítačové bezpečnosti je taková, že když má útočník přístup k vašemu HW, bezpečnost jde do háje. To byste mohl (resp. měl) vědět.

Ve Windows k těm heslům máte přístup, i když máte pouze právo ke čtení shadow copy, které můžete mít klidně vzdáleně, a to přesto, že všechna vaše ostatní data jsou v bezpečí, protože je máte šifrované (i když u toho si nejsem jistý, jak složité by bylo z Windows vykuchat ten šifrovací klíč, který zcela evidentně nemůže být chráněn heslem?). V Linuxu jsou ta hesla alespoň hashovaná tak, že nejdou rozluštit, v lepším případě je šifrovaný celý disk a zálohujete jej tak.

Pokud máte práva na čtení shadow copy a práva ke kritickým souborům, samozřejmě je přečtete (na Unixech se ani nemusíte obtěžovat se shadow copy). Hashe hesel nejsou salted, ale jsou šifrovaná. Heslo se samozřejmě dá dohledat.

Pokud jde o rainbow tables, je to sice efektivní technika, ale tabulky jsou velké. Od verzí Windows Vista a Server 2008 MS by default neukládá slabé LM hashe, a rainbow table NTLM hashů pro 9-místné heslo má okolo 1TB. Kolega Jiřík má buď 1TB USB klíčenku :), nebo používá nějakou prehistorickou verzi Windows.

A šifrování disku? Šifrovací SW (TrueCrypt, BitLocker) potřebuje mít za běhu klíč v paměti. Dump paměti dostanete například tak že stroj resetujete a zabootujete z USB klíčenky - většina paměti zůstane neporušená. Nebo obraz paměti vytáhnete z běžícího stroje přes nějaké rozhraní: Express Card, PC Card, Thunderbolt, 1394. Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
http://technet.microsoft.com/library/cc722487.aspx

S Rainbow Tables a se šifrováním disku máte pravdu.

Problém s NTLM hashi (pokud jsem si to přečetl správně) je v tom, že ke spoustě služeb (třeba v doméně) mi stačí znát ten NTLM hash, a nepotřebuju zjišťovat původní heslo. Hash hesla z /etc/shadow v linuxu mi nic takového neumožňuje.

O tom nic nevím. Dáme mi k tomu prosím víc informací?

Tak jsem si to špatně spojil. Viz http://en.wikipedia.org/wiki/NTLM . Znalost NT-hashe a LM-hashe stačí na přihlášení se pomocí protokolu NTLMv1. Znalost NT-hashe a v2-hashe (možná je to ten o kterém jste mluvil v příspěvku výše) stačí na přihlášení pomocí NTLMv2. Samozřejmě pokud administrátor domény povolí jen kerberos, tak by znalosti hashů měly být k ničemu.

1 TB je podle vás moc velké? To žertujete, že? Co takhle ty tabulky najít předpočítané? A aby to nebylo málo, NT hash je MD4. Hashovací algoritmus, který je dvacet let (!!!) prolomený. Bez soli. Až se divím, že se MS vůbec obtěžuje ty hesla ukládat jinak než v plain textu.

Opět opakuji, u Windows ani nepotřebujete mít přístup k hardware, stačí mít vzdálený přístup a právo číst disk. Což by nikdo nepředpokládal, že bude tak strašně nebezpečné.

1TB při 9-místném heslu. S každým dalším znakem hesla jsou ty tabulky výrazně větší.

OMG. Databáze jsou podle vás zřejmě velmi nebezpečný sport. Uživatelská hesla jsou běžně hashovaná, a stačí mít vzdálený přístup k souborům DB. Přitom je to tak jednoduché: nedávejte bad guys přístup k hashům.

Uživatelská hesla jsou běžně hashována algoritmy, které pokud možno nejsou prolomené, a s přidanou solí. Oboje z celkem rozumných důvodů. Např. MD5 je sice tak trochu prolomené (sice ne jako MD4, kde jste už v roce 1995 mohl najít kolizi za pár sekund, ale za určitých okolností lze vytvořit kolizi), ale díky soli vám ani tak nestačí najít libovolnou kolizi. U NTLM vám stačí najít první kolizi a můžete se přihlásit (nehledě na to, že v mnoha případech vám stačí jen ten hash a ani ho nepotřebujete lámat).

Přitom je to tak jednoduché: nedávejte bad guys přístup k hashům.

S tímhle přístupem je úplně zbytečné plýtvání výkonu počítat nějaké hashe ;-)

To je samozřejmě nesmysl. NTLMv2 používá hash hashe.

NTLMv2 používá hash vypočítaný z hashe hesla, user name a domény. Toho hashe hesla, který si můžete vytáhnout z Windows. To je naprosto parádní zabezpečení, když vlastně vůbec nepotřebujete znát heslo :-)

Mimochodem zřejmě pro rozšířenou bezpečnost je ten hash pořád stejný. Termín „nonce“ a jaký má význam při autorizaci pomocí hashů asi MS nikdy neslyšel.

Fajn, tady máte jedno heslo z databáze, obsahuje pouze 4 malá písmena, hash je SHA1, předveďte se:

5189d1d6ed208­c54c69d51e118a357e­af84f736f

Už jsem vzdal "mlácení o hlavu" u M$ SQL serveru. A hledat jejich memory-leaky se mi fakt nechce :-)

Uz se ti stalo, ze si M$ sql je tak znicehoz nic vzpomel, a smazal vsechny data? Me uz jo ... cumel sem na to jak puk, vsechny soubory v datovym adresari byly vpr... Nakopirovat ze zalohy par stovek GB precijen chvilu trva ... (a to sem fakt jen kopiroval, kdybych mel pouzivat integrovanej zalohovac, trvalo by to tak 1/2 den)

Staci mit na fileserveru se statisicem drobnych fajlu nejaky antivirus, napr. NOD32. Pak behem tydne server zpomaluje az je cekani na fajl nesnesitelne - staci restart serveru a je vse OK... odinstalace antiviru a nebo restarty, vyberte si :-)

A nebo kontaktovat podporu ESETu, případně vyměnit antivirus. Teď vybírejte.

Anebo použít systém, který antivirus nepotřebuje, protože není děravý jak řešeto

A vy víte o nějakém systému, který není děravý jako řešeto? Linux to rozhodně není :)

Vis loliku, v tuxovi si user bezne nemuse spustit binarku, odkud se mu zlibi. A taky se mu nestane, ze by si nahodil tuxe neopatchovanyho, a deravyho hned pri instalaci.

Rozhodně není tak děravý, aby potřeboval speciální aplikaci žeroucí nezanedbatelné množství systémových prostředků jen pro ucpávání těch děr.

Děravý je, ale vzhledem k zanedbatelnému rozšíření na desktopech většinou nestojí autorům virů za úsilí nutné pro psaní malwaru.

No já si myslím, že zavirovat takové servery Googlu, Facebooku, Seznamu nebo většiny bank by bylo pro autory virů mnohem zajímavější než zavirovat nějaké windowsí servery. Jenže reálně to jsou právě ty windowsí servery, co musí s viry každý den bojovat.

Pletete si veřejné internetové servery s těmi firemními. Veřejné weby na LAMP, případně nedej bože na Wordpressu, jsou často (a úspěšně) cílem úroků. Pokud jde o firemní servery, tak tam jde primárně o ochranu desktopů. Proto když dojde na použití linuxového serveru, najdete antivirus často i tam.

Vzhledem k tomu loliku, ze tuxe ma doma kazdej doma tak 5x, vs widle, ktery ma mozna 1x ... bych o rozsirenosti vubec nemluvil.

Jedna domacnost = rekneme 3 telefony (3x tux), 2x tv (=2x tux), nejaka ta routokrabka = tux a mozna jeste 1x v aute. Vs tak 1x PC s widlema.

Proč sem taháte OS na telefonech a v autech, když byla řeč o desktopech? Máte nějaký problém se soustředěním?

Můžete si všimnout, že jsem začal k diskutovanému tématu, a pak jsem směřoval k něčemu jinému. Kolega první část nějak přeskočil, nebo se mi ji v jeho příspěvku nepodařilo dohledat :)

Já fandím Spartě, manželka fandí Spartě :), Franta taky, chlapi v práci jakbysmet... Kde jsou všichni ti slávisté?

Já mluvím česky, manželka mluví česky, naše děti mluví česky, prodavačka v obchodě mluví česky... a pak prý že je nejrozšířenějším jazykem čínština.

http://en.wikipedia.org/wiki/Selection_bias

Ty tagy :-D

Hele, ty jen kopirujes data, to muzes v nejhorsim poresit pripojenim disku k nejakymu tuxovi, ten na prava z vysoka ... ;D

Ale kdyz mas AD (neboli slavnou M$ domenu) to je teprve zazitecek. Premigrujes usera z Xp na W7 (trebas) a ... voiala ... user ma svy data v pr... protoze M$ zalozi na serveru novej, cistej profil. Ten starej samo zmigrovat neumi, a zadnej nastroj na to nemaj. Takze muzes zacit pekne rucabo kopirovat. Samo to znamena, ze prestanou fungovat i M$ applikace (trebas utlouk), protoze jejich nastaveni je ... v profilu. Zuzo.

Kdyz sem menil distro tuxe, tak sem vzal /home, a bylo zmigrovano ...

njn, domain controler ... ;D

kolega onehda v ramci vylepseni bezpecnosti provozu nahodil sekundarni. A pak se zcela random useri dozvidali, ze nemaj prava na to ci ono. Samo kdykoli sme to zacli zkoumat, tak bylo vse naprosto koser ... mno asi po 3ch mesicich, kdyz uz to vypadalo ze nas useri sezerou, proste ten sekundar vypnul. A voiala, zazrak, samo se to spravilo ;D.

Samozrejme, v logu nic, vsechno aspon 50x zkontrolovany, naconfeny presne podle dokumentace ...

Pak jeste zkusil nechat bezet sekundar a vypnout primar ... to fungovalo uplne stejne dobre. Ale oba zaroven ani za boha.

Tipuji odpověď mistra Laela v duchu toho, že jste neschopný admin, který dělá ostudu své profesi a že chyba je samozřejmě u dodavatele, proto si to prosím vyřiďte s tím, kdo vám disk a PC dodal :-D

Jestli ono to nebude tím, že Application Data není adesář :). Od Visty dále jsou tahle data v adresáři %USERPROFILE%\Ap­pData\Roaming. Application Data je jen link, který existuje kvůli kompatibilitě se špatně napsanými aplikacemi. Přesvědčit se můžete příkazem dir /a:l

Je dost smutné, že nevíte a neznáte, a v důsledku z vás padají nesmysly jako "shit" a "parodie na OS". Předpokládám že kdybych třeba já neznal koncept hardlinků na Unixech, narazil na něj a psal pak něco o shitu a parodii na OS, myslel byste si něco nepěkného jak o mých znalostech, tak o mých schopnostech analyzovat problémy. Uvědomte si prosím, že přesně v téhle roli jste vy.

OK, zkuste si ten dir /a:l a přijďte se pochlubit výsledkem.

Ad to vám přijde normální, že příkaz pro změnu vlastníka by neuměl traversovat link, popř. napsal, že u linku neumí změnit vlastníka - jestli to tak opravdu je, tak to nepotěší. Ale mě daleko víc nepotěšilo, když mi například všechny utility na Linuxu odmítly založit šestnáctou partition na RAIDu, a žádná mi nedala srozumitelnou hlášku, že to prostě nejde.

Aha, a co třeba disk quotas? Pokud je máte zapnuté a admin je překročeno povolené místo, zkuste dočasně vypnout nastavení Deny disk space to users excededing quota limits. Kvóty najdete ve vlastnostech disku, jsou tam i quota entries.
http://i.technet.microsoft.com/dynimg/IC244471.gif

I kdyzž je pozdě, tak pokud se setkáte s tímto problémem do budoucna, tak zkuste icacls.exe (tahle aplikace je docela dost silná, umí přebírat i oprávnění tam, kde GUI selhává - zvláště u creator ownera).

Jinak Jsem si čtením těch komentářů tady prodloužil život tak o 10 let (jen shrnutí: Indoš=tunel; rozumný klient pro Exchange = on nějaký existuje?, v jednom kuse mi to synchorniuje data se serverem, asi si vypnu tu offline cache, navíc mi to příjde jako naprosto zbytečné řešení, když vemu v potaz, že používám kalendář, tak si vystačím bohatě s Googlem, profesionální nástroj na tvorbu dokumentů = ten tady ještě zmíněn nebyl, ano je to LaTeX, v neposlední řadě takové sra*** jako Publishe netřeba komentovat, nesetkal jsem se s moc kladnými ohlasy, jo a po čerstvé instalaci Win8.1 po te, co mi update z 8 na 8.1 smazal složku Installer - v podstatě všechny MSI aplikace šly do kytek, mi nejel ani skydrive, musel jsem dát skydrive stop, skydrive reset a skydrive, pak se rozjel). Jen taková perlička:

Mám Windows Servery 2012-R2 a mám udělán snapshot. Dva týdny jsem na ten snapshot instaloval různé buildy jisté aplikace (.Net 4, nepodpora klientského OS) a naprosto bez problémů, vždy jsem pak obnovil snapshot, po dvou týdnech prostě nic, chybová hláška odkazující na problém s .Net a toť vše. Zkoušel jsem i buildy, které na tom před tím jely a prostě nic. Teď se ptám (řečnicky, ironicky, to je jedno), proč mi naráz přestal fungovat snapshot (já myslel, že si má uchovat aktuální stav systému, ale evidentně mají v MS vyšší plány - ano bylo to MS Hyper-V ovládáne System Center Virtualzation Manager, nebo jak se to jmenuje). V Linuxu, VMWare ani v Oraclu se mi nic podobného nestalo (pokud jsem si to nezapříčinil sám - rád experimentuji a viruálky jsou na to super).

Odpoved na recnicnou otazku ... protoze ses blbej admin, kterej nicemu nerozumi ... nebot lolovi vse funguje a nikdy nevidel zadnej problem.

Hele, ja se pravidelne trebas potykam s wsusem, kterej neumi smazat nepotrebny patche, takze uloziste ma stovky GB ... a pravidelne dojde misto. Kdyz spustis ten jejich uzasnej mazaci dzob, tak bezi desitky hodin a stejne nedobehne.

Nevím jestli je kolega Withy14 špatný admin. U vás o tom nemám pochybnosti.

WSUS umí mazat nepotřebné patche. Když s tím ale začnete po několika letech provozu, je jich tolik, že běží desítky hodin. To je pak jednoduší provést WSUS reset.

Ad snapshot - nevím. Zkusil bych jít po té chybě odkazující na .NET. Mohl se vám také do toho systému někdo hrabat (ne všechny problémy jsou čistě technické), nebo mohlo dojít k něčemu v závislosti na čase (třeba Windows Update).

LOL a z webového serveru máme rázem vesmírnou stanici :-D

IIS používá worker procesy, které pravidelně recykluje. Případné resource leaky (ať už na úrovni aplikace nebo IIS) se tak nemají moc šancí projevit.

Mno prave proto ze je nerecykluje, je treba ho pravidelne restartovat.

Na prvním místě je recyklace poolu pouze workaround pro špatně napsané aplikace.

Pokud se pool nerecykluje, buď je v kódu aplikace deadlock, nebo máte někde jiný problém. Samozřejmě lze zjistit příčinu problému, ale pro klikače bez znalosti IIS je to asi nemožné. V takovém případě doporučuji kontaktovat autora aplikace, případně nějakého jiného profesionála.

Co, IIS nekontroluje deadlocky workerů? LOL :-D

Samozřejmě že detekuje. U pana kolegy ale zjevně někde něco nefunguje, a nemá dost erudice, aby vymyslel něco lepšího než restart serveru.

Pokud detekuje deadlocky, jak se může stát, že takového workera potom nezrecykluje? Nebo je detekuje a tím to skončí?

Měl by, ale byla by to jedna z oblastí, kde bych začal s troubleshootingem. Samozřejmě nemám dost detailů o problému, který pan kolega neumí řešit. Jako admin by ale měl být schopný dělat troubleshooting tohoto typu. Admin by neměl být lama, která umí jen klikat na restart.

loliku, denni restart je postup od autora aplikace, ktery je samosebou a jak jinak, partnerem M$. Dokonce tuto aplikaci tak zcela standardne implementuji (s tim restartem).

Partnerský program MS nijak nevypovídá o kvalitě aplikace, kterou takový partner (kvalifikovaný podpisem smlouvy) podepíše.

Jinými slovy vám někdo dodal špatně napsanou aplikaci. A protože jede na Windows, je to samozřejmě problém Windows. Kdežto kdyby aplikaci autor zprasil pro Linux... samozřejmě by to byl problém autora, že? :D

Nikoli loliku, takovy aplikace dodava i M$, kuprikladu slavne reporting services. Ty taky 1x tydne restartuju, protoze jinak trva nacteni reportu i nekolik minut. A roste to exponencielne s casem, po ktery ty widle bezely. A ne loliku, nic jinyho nez ty reporting services na tom stroji (krom holych widli) neni. Presto trva zobrazeni reportu ( i za normalnich okolnosti) nekolikanasobek casu, co trva samo query. A to jde o zcela trivialni generatorem vygenerovanou tabulku. nedovedu si predstavit, ze by na ten srv pristupovalo vic nez tech nekolik jedincu co to pouzivaj.

Reporting Services jsem, Jeníčku, nikdy nepoužíval. Ale jako super-schopný admin, kterého jsi ztělesněním :), jsi jistě dávno prošel zdroje informací a něco o věci načetl. Nebo tě platí za psaní na rootu?
http://technet.microsoft.com/en-us/library/bb522786(v=sql.105).aspx
http://technet.microsoft.com/en-us/library/bb522806(v=sql.105).aspx

Btw. proč dává MS do nesématických URL závorky?

Protoz je to M$ :D
Stejne by ses moh zeptat, proc si lolik nezobrazi nahled, pripadne nepouzije v zapati dokonce vyjmenovany tagy.

Pokud k těm leakům nedochází ve sdílené paměti

Tak důvod vyplaval, je to v jádru Win a IIS... http://diit.cz/clanek/mnichov-se-na-windows-nevraci/diskuse#comment-726928 dolní část komentáře.