no docela by mne zajimalo opravdu objektivni srovnani celkovych nakladu na provoz dejme tomu site s 300 pc (takova stredni firma). Ani bych se nedivil ze celkove naklady u win ekosystemu budou nizsi nez u open source kde se sice usetri na licencich, ale vyda majlant na supportu (z cehoz ostatne zije RedHat ..) a o absenci centralizovane spravy nemluve .. neumim si predstavit jak nas IT spravce by to nejak centralizovane kociroval ...
priznavam ze o tom, jak se centralne spravuji linuxova pc mnoho nevim, jen by mne zajimalo jake jsou naklady na zaskoleni obsluhy (it spravce) na win platforme a linux platforme a taky kolik casu tomu potom ten spravce musi u obou platforem venovat jestli "to proste funguje" nebo "musim furt neco resit, nastavovat, konfigurovat, hledat reseni ..)
Nejde ani tak o zaškolení, firma prostě přijme správce pro Linux, nebo Windows. A vím že rozumně nakonfigurovaný linuxový server prostě běží a pokud se nejedná o HW problém, nebo útok zvenčí, takřka o něm nevím. U Windows jsou problémy, ať už s pamětí (je jedno kolik jí je instalováno, pořád je to málo), tak i s podivným chováním, protože se jedná o blackbox. A to už vůbec nemluvím o aktualizacích. Na Linuxu se prostě restartuje služba která byla aktualizována a nikdo nic nepozná, na Win je většinou potřeba provést restart. Díkybohu už se u serverových oken nerestartují po aktualizaci samy, jak to bývalo u těch starších :-)
jak si predstavuji v nasi firme IT spravce (zena) jak prechazi na linux centralizovanou spravu a ona by proste potrebovala z gruntu od nuly nove skoleni, funguje u nas jak ferda mravenec, stara se sama o 300 pc, od vypadle snury, pridani ramky, skladani hw pc, pres site, konfiguraci vseho, aktualizace vsech aplikaci, mame i zivotne dulezitou aplikaci bezici na oracle a server na kterem bezi, jinak trend asi bude tenkej klient (aplikace klient - server) resp. webove aplikace a boj o penize uz se bude odehravat jen na strane serveru, zamestnancum je fuk na cem ten server pobezi.. je backend nezajima, jen klikaci frontend ...
Na vic nez polovine widlich serveru mame nastavenej pravidelnej denni/tydeni restart. Duvod? Proste se to zacne chovat divne - bez jakychkoli logu samo.
Ostatne, nejvic jsem se nasmal, kdyz majitel vznesl dotaz, jak to vidim s provozem 24/7. Na widlich (a s widlima aplikacema) naprosto neresitelny. Mam tu ISko, ktery si noc co noc restartuje IIS, coz samo vede k odstreleni vsech klientu, duvod je, "aby se nezaplnila ram".
Muj apache bezi aktualne cca 1/2 roku od posledniho restartu ...
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ě.
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.
Proto jsem psal, že v našem případě. Ono taky záleží, kdo a jak to nastavil, správně nastavit Exchange není jednoduchý. Jen pustit setup nestačí, část věcí se pak musí doladit podle hlášek v event logu, často přímo v powershellu. Zrovna Exchange nepatří mezi vyslověně klikací softy, taky byl myšlený hlavně pro větší firmy.
Kolik měl ten comp RAMky? A bylo tam zároveň DCčko (což je nedoporučovaná varianta)?
Našel jsem ten původní příspěvek, DC tam asi bylo. Tím, že je to nepodporovaná kombinace, tak některý věci po instalaci Exchange nefungujou správně. Jedním ze známých problémů je právě dlouho trvající restart (běžně 1/4 hodiny). Buď se dlouho vypíná a nebo pak naopak nenastartují všechny služby a musí se něco nahazovat ručně. Jde to vyřešit, jsou na to postupy, ale chce to víc práce a hlavně o tom musí člověk vědět.
SBS to má nějak pořešené, aby to dohromady fungovalo bez ladění, ale ten neznám. Jinak i my máme DC a Exchange dohromady.
Tomu věřím. Ale není hlavní důvod to, že do postfixu vidíš a do Exchange tolik ne? Já bych měl zase naopak větší problém s nastavováním postfixu. Každý umí něco jiného a tak je to správně.
Jinak jak psal předřečník, funkčnost postfixu je jen *malou podmnožinou* funkčnosti Exchange. Nejde to úplně srovnávat.
A Samba nerovná se AD. SMB sdílení je podporovaný na jakýkoliv roli serveru, tj. samozřejme i spolu s Exchange.
> Ale není hlavní důvod to, že do postfixu vidíš a do Exchange tolik ne?
Ten mrtvolný stav jsem nezpůsobil já, takže to je irelevantní, nakolik do toho vidím já. Nicméně nevím, jak by někdo mohl dokázat, aby postfix způsoboval čtvrthodinový start serveru. To dost dobře nejde právě proto, že postfix nepoužívá neprůhledné nespravovatelné jediné úložiště, které když se posere, nikdo to nedá dohromady.
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.
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?
Vy si to ale, Vazeny Loliku, predstavujete jak Hurvinek valku.
Modelova situacia, ku ktorej som sa minuly rok primotal. Statny urad vyuziva "webovu aplikaciu", monstrozitu beziacu len na kombinacii WinServer 2k3 + ISS6 + IE9.
Dodala to firma, ktora k tomu prisla cez vyberove konanie (dokonca asi nepodmaznute), pricom to cele bezi na frameworku externej, nemeckej firmy. Support je docela fajn, chalan na drate sa ide pretrhnut, aby pomohol, ale v praxi nezmoze moc a vsetky realne problemy deleguje vyssie, niekedy az do toho nemecka. Pricom samozrejme, za support sa plati nemeckou cenou, i tym Slovakom, takze s nim clovek nemoze jednat prilis casto :p
Mno a problem je v tom, ze ten IIS zamrza. Neviem, ci je to bug, leak, alebo proste made in MS, kazdopadne na tom stroji nebezi nic ine, HW je virtualny, host 100% v poriadku a ak zamrzanie sposobuje samotna aplikacia, dodavatel to rozhodne neprizna.
Vyjadrenie MS je cca v tom zmysle, ze oni uz svoj SW nepodporuju. Zial, cela ta vec je opatrena asi kilom certifikacii a akykolvek upgrade je absolutne nepodporovany. Bol by teda na zodpovednost toho, kto ho schvali a to je pri IIS profesionalna samovrazda :)
Preto teda dodavatel potvrdi existenciu problemu a odporuci nocny restart.
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.
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 ...
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.
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.
> Proto se widle rovnou reinstalujou, protoze je to asi tak o 10 radu levnejsi a efektivnejsi.
Chtěl bych vidět toho Laelova kvalitního admina, jak na stovkách stanic analyzuje problémy typu Systém událostí modelu COM+ nemohl vytvořit instanci odběratele ... :)
To by pak cena licence v celkových nákladech byla naprostá nula a nebylo by vůbec smysl ji řešit :)
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.
Aha. Takže když je u vás nemáte, kdy jste je naposledy viděl? Jaký OS v jaké verzi? A spravoval jste ho jak dlouho? Na jaké pozici?
Jinak pod "unixové" myslím všechny skutečné unixy i unix-like systémy. Tj. i Linux, o jehož penetraci na serverech se snad nebudeme bavit, nebo jo?
A pokud byste měl zájem o skutečné unixy, tak např. Netflix provozuje svoji CDN na FreeBSD, takže nejméně třetina severoamerického internetového provozu je obsluhována unixem :)
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á.
Nenajdete. Najdete ID udalosti, co je len poradove cislo v logu, uzitocne jak sanky v mori.
Ja vam to kludne odcitujem:
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7031
Date: 8/24/2014
Time: 13:52:05 PM
User: N/A
Computer: serer14
Description:
The Print Spooler service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 5000 milliseconds: Restart the service.
V detailoch sa dozviete kody pre horeuvedene "riesenie" a hexa zapis slova "Spooler". Ze to sposobuje "vhodne" formatovane PDF v tlacovej fronte, pravdepodobne v spolupraci s driverom HP, na to musite prist metodou pokus-omyl.
Opat raz musim vyjadrit svoje podozrenie, ze ste zivi WinServer este nevideli :)
Event ID není pořadové číslo události v logu. Je to ID (typu) události, v tomto případě EVENT_SERVICE_CRASH.
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.
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.
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".
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.
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.
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.
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.
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 ...
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.
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? :)
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.
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.
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 ;-)
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)
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.
http://www.root.cz/zpravicky/android-a-ios-stale-rostou-ostatni-se-propadaji/
Lael Ophir (neregistrovaný) ---.145.broadband14.iol.cz
19. 8. 2014 5:25
Re: Pokles WP
celé vlákno</b>
Zákazníci to třeba vidí tak, že jsou WP druhou nejrozšířenější mobilní platformou. V Evropě mají WP 8.5% trhu. A i když ta celosvětová procenta by mohla být lepší, zrovna fanoušci Linuxu nemají moc co křičet. Jejich tučňák se přece na desktopech nedostal na ta procenta WP ani za 22 let, a přesto nevyléčitelně věří, že už zítra to musí vyjít :)
Doufal jsem, pane Ophire, že se na pokec u tohodle tématu stavíte. Měl bych na vás opět otázku:
Kde přesně bych měl hledat problém, když se na Windows serveru stane tohle:
https://plus.google.com/109540561880466469418/posts/PQCAbxKtEGL
?
V logu serveru samozřejmě nic. Když jsem disk vytáhl a připojil k jinému počítači, proběhla operace bez problémů.
Splňuje tenhle příklad dostatečně definici "divného chování"?
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 ...
Tahle akce byla právě v rámci umravňování jednoho hodně zanedbanýho a totálně umrtvenýho AD severu :) Jenom jeho nastartování trvalo (ještě dokud tam byl Exchange) asi 15 minut :)
Nutno říct, že samba 4ka je taky pěkná prasárna, ale aspoň má člověk jistotu, že se dostane k datům a nebude několik dní řešit jenom dementní práva k souborům :)
S těna profilama je to dementní, ale aspoň ty V2 profily mají trochu hezčí strukturu...
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.
Jestli ono to nebude tím, že Application Data není adesář :). Od Visty dále jsou tahle data v adresáři %USERPROFILE%\AppData\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.
> Jestli ono to nebude tím, že Application Data není adesář :)
Nebude, protože to byl adresář v profilu Windows XP uložený na Win Serveru 2003. Čili úplně normální adresář. A nedělal to jenom tenhle, dělalo jich to spousta. Takže zkusme nějakou jinou teorii.
Jinak, 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?
> Je dost smutné, že nevíte a neznáte
Důležité je, že vy víte a znáte, co je adresář na disku, který jste nikdy neviděl :)
> 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
Pokud by příkaz "chown lael hardlink" napsal, že není místo na disku, tak byste na to měl plné právo. Problém je v tom, že žádný unix tohle neudělá.
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.
> OK, zkuste si ten dir /a:l a přijďte se pochlubit výsledkem.
Mile rád se pochlubím: "File not found". V /a:X je pro X povoleno jenom D,H,S,R,A,- Aspon tedla podle dir /?
:)
Ale vážně: link to prostě není. Už proto, že kdybyste se pořádně podíval na ty screenshoty, na prvním z nich stejná chyba vypadne na nějakém XML souboru.
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.
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.
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.
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
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.
S něčím jako každonoční restart serveru bych se nesmířil. Z práce (asi 40 Win serverů) mám zkušenost, že skoro všechny problémy lze nakonec vyřešit, i když někdy to opravdu trvá dlouho. Když už nevíme sami, tak zavolám někoho z Gopasu. Většinou za pár tisícovek pořeší problém, který bychom sami řešili týdny. Zkuste se jim ozvat, znají věci, o kterých jsme (jste) ani nevěděli, že existují.
Jinak aplikační pooly (procesy) IIS se ukončují po minutách nečinnosti a navíc se každý den restartují jako ochrana proti blbě napsaným aplikacím. Obojí lze samozřejmě změnit. A lze zařídit, aby restart app pooolu neodhlásil uživatele. Myslím, že blbě napsaná aplikace může přetížit nebo jinak znefunkčnit server jakýkoliv platformy. Ale restartovat kvůli tomu celý server? Není to jako kanón na vrabce?
Jinak naše aplikace na IIS běží taky klidně neomezeně dlouho, pokud v nich není chyba. Myslím, že to není o systému.
No ono asi jde také o to, jak kvalitní ten support bude. U opravdových odborníků a ne jen bastlířů/klikačů nejspíše nebudou zas tak velké rozdíly v tom, za jaký plat jsou ochotni pracovat.
Jinak určitě jde ošéfovat i ta centralizovaná správa, neříkejte že ty tisíce hostingových firem, které spravují unix-like-servery dělají vše ručně. Navíc unixové systémy mají lepší dokumentaci a možnosti přizpůsobení, než Windows řešení, kde se většina nápovědy omezí na lakonické „kontaktujte svého správce sítě“.
lol ... cca 100PC s win, minimalne 2-3x tydne se resi, ze "neco" nefunguje. V jednom az 2 z tech pripadu, se to po cca 1/2 dni prace ITka povede nejak poresit (nebot vzhledem k neexistenci logu trva neuveritelne dlouho zjistovani, proc to, co na 98 PC funguje, na tom 99 ne). Minimalne jeden z tech podelanych stroju jde na reinstal. To samozrejme plati za "bezneho" provozu. V okamziku kdy jsou do site pusteny M$ aktualizace, se pocet potizi znasobi.
Duvodem je v 90% pripadu to, ze na widlich proste neexistuje zpusob, jak udrzet ty widle ve stavu, v jakym si je nainstaloval. At chces nebo ne, do registru se naustale zapisujou dalsi a dalsi sracky.
Jinde +- 30 stroju na tuxovi. Takze (pokud by to bylo ciste pomerny) by se mel resit aspon jeden tydne. Jenze... neresi. Mozna tak kdyz se jde delat upgrade distra, tak se narazi na nejaky problemek, jenze ten se vyresi 1x ... a pak na vsech strojich stejne. Tohle na widlich taky nefunguje, protoze kazda instalace i na totoznym HW je unikat.
Mam tu dobre 60 zcela totoznych stroju na widlich a presto kdyz ty widle nainstaluju cisny, tak se na kazdej instalujejinej pocet patchu, a nektery (pokazdy jiny) neprojdou ...
O centralizovany sprave zjevne vubec nic netusis, nastavim autentizaci vuci ldap/radius a co se patchu tejce, instalujou se na tuxovi zcela jednoduse ... takze je jen vsem predhodim do spolecnyho repa. Dtto pripadna instalace neceho novsiho, staci to predhodit a klient si to sam prechroupe. Jako bonus se mi nekopirujou GB sracek v podobe "lokalni cache" do utlouku na kazdej jeden stroj 20x, kdyz na nem dela 20 llidi.
....
Podotykam, ze mluvim vyhradne o widlo potizich, ne samo o dalsi hromade problemu s aplikacema samotnejma. Kupdikladu widle jsou tak uzasne kompatabilni, ze na Win 7+ sice spustim aplikaci z win xp (od M$), ona dokonce neco dela, ale blbe. Jop a jejich XPmod je samozrejme ve firemnim prostredi naprosto k hownu a zcela nepouzitelnej. Realne to totiz znamena adminovat dvojnasobej pocet sytemu, vcetne jajich zarazeni do AD a spustu dalsich ficur, vcetne toho ze ty Xpcka chteji samo vlastni Ipcka ...