Příspěvky

7216

Windows a jiné systémy / Re:WindowsBackup - Event 129 během zálohování Windows 2012 Std

« kdy: 01. 09. 2015, 14:50:10 »

No, mozna by stalo za to nahodit nejaky free soft, jako Bacula, ktera je snad zadara a zkusit, co to udela s tim. Ntbackup je dost strasny a je dobry tak na zalohu Widli samotnych, protoze umi system state, coz kazdy backup neumi.

7217

Windows a jiné systémy / Re:WindowsBackup - Event 129 během zálohování Windows 2012 Std

« kdy: 01. 09. 2015, 13:35:46 »

Tak tady https://social.technet.microsoft.com/Forums/windows/en-US/975a312a-fd49-4db5-8a38-e3961ae0a1e9/event-129-vhdmp-during-backup-windows-2012-std?forum=windowsbackup se pise:

"
Question
Sign in to vote
0
Sign in to vote

Hi,

So if you separately backup each partition, only the third one will fail with the event 129 error?

From the article, there is a Time-out value (HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue) which should longer than the time a backup is running. So please check if the issue occurs when the partition (or disk) is busy.

It is not recommended to edit the value so you may confirm with your storage vendor if it is OK to modify."

Tedy to vypada na editaci registry, kterou tentokrat nedoporucuje nejen Lael Ophir, ale i jini. Tak bych zagoogloval, jestli ten klic znamena opravdu to, co rikaji a jaka jsou doporuceni, jak s tim zachazet. Tedy je to zase MS pakarna.

7218

Windows a jiné systémy / Re:WindowsBackup - Event 129 během zálohování Windows 2012 Std

« kdy: 01. 09. 2015, 12:53:15 »

Ze by http://blogs.msdn.com/b/ntdebugging/archive/2011/05/06/understanding-storage-timeouts-and-event-129-errors.aspx ? "The most common causes of the Event ID 129 errors are unresponsive LUNs or a dropped request."

Jinak priste zkuste Widle v anglictine, ty hlasky se lepe googluji a vymyslet presny preklad neni vzdy tak jednoduche, zejmena pak pri kvalite ceskych lokalizaci. Treba vam blbne jedna hlasitost.

7219

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 01. 09. 2015, 12:47:06 »

V tom případě jsem asi nepochopil smysl vaší poznámky o tom, jak je to udělané

To je jedno, tahle diskuse je skoro cela nepochopitelna. Ale vyplyva z toho, ze si nerozumime, tak spolu radsi nebudeme chodit.

7220

Distribuce / Re:Arch Linux - obnova hesla

« kdy: 01. 09. 2015, 12:42:25 »

Mozna by stalo za to zminit, jak zeditovat. Doufam, ze ted moc nekecam, protoze tento problem jsem mel naposledy tak pred patnaci lety :-), ale melo by stacit zeditovat odpovidajici radek v /etc/passwd. Priklad:

root:x:0:0:root:/root:/bin/bash

Vymazanim pismene x za dvojteckou za jmenem uzivatele by mel vzniknout uzivatel bez hesla. To x znamena, ze vlastni heslo je v /etc/shadow. Jeste po tom zbyde bordel v /etc/shadow, ale ten by mel byt zkorigovan pote, co je uzivateli znovu nastaveno heslo.

7221

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 01. 09. 2015, 12:22:10 »

Ok teraz konstruktivna otazka, par hodin sa snazim zablokovat komunikaciu windows 10 zo svetom, na nieco funguje hosts na nieco firewall ale ani jedno nefunguje na deploy.static.akamaitechnologies.com.

Co takle zkusit na Widle naistalovat firewall od nekoho jineho? Mozna ZoneAlarm, pokud neni prilis primitivmni na to, aby blokovani tohoto typu neumel. ZoneAlarm me z firewallu, ktere jsem kdysi zkousel, vytacel nejmene. Nektere mely dost uzivatelsky nepratelskou konfiguraci, u ZoneAlarmu obvykle staci odpovidat na dotazy ano/ne +zapamatovat pro priste.

7222

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 01. 09. 2015, 12:20:36 »

A kdyby to rozpakovávalo do ramdisku, už by se vám to líbilo víc? Nebo kdyby to rozpakovávalo po částech?

Tak to vyjde na stejno, ne? Krome toho by archivemount musel byt napsa tak, aby si dokazal najit ramdisk a pouzit ho nebo by se mu muselo explicitne rici, kde je ramdisk. Takze do ramdisku se bude rozpakovavat leda tak tehdy, kdyz na nem mam /tmp. Coz muze byt problem, pokud mam soubor zip o nekolika MB, ktery obsahuje ridky soubor o velikosti 70 GB. Tolik RAM nemate, co?

Celkove ale nechapu smysl poznamky o rozpakovani do ramdisku.

7223

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 01. 09. 2015, 12:12:50 »

Původně jsem chtěl napsat něco jiného, ale:

Prosím roota, aby tohle vlákno hodil do /dev/null. Žádná konstuktivní diskuze tady neproběhla a ani už neproběhne.

to Lael a spol z M$: tohle je root! Server zaměřen na Linuxy, pokud nemáte nic konstruktivního, tak aspoň nemrvte diskuzi
to Linux users: prosím neživte diskuze takového typu jako je táto (trolování, urážky apod., nemá to smysl, nemělo a ani mít nebude)
to root: v případě, že spatříte takovouto diskuzi, tak ji proboha buďto zmoderujte a/nebo lockněte!

Hele, nekecej nam tu do toho. My tady testujeme, jak velke ma Root diskove pole!

7224

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 01. 09. 2015, 11:07:45 »

Tak jste se opět chytil do pasti. Čekal jsem, až zase napíšete nějaký svůj blábol plynoucí z vaší neznalosti a sežral jste to i s naviákem. Ony totiž takové implementace existují a normálně je používáme. Viz. http://man.devl.cz/man/1/archivemount. Funguje to zcela transparentně, aplikace vůbec nevědí, že pracují s vnitřkem ZIP souboru, jeví se jim to jako soubory. Fungují na tom běžné operace na práci se soubory.

To jo, ale otazka je, jak presne archivemount funguje. Zdrojaky jsem nestudoval, ale cekal bych, ze aplikace primo se soubory v zipu nepracuji. Spis to, ze pri otevreni souboru se tento rozpakuje do /tmp, podstrci se aplikaci a ta si ho spokojene bude chroustat. Pri zavreni se nejspis ten docasny soubor schova a v okamziku odmontovani archivu se pouzije k vygenerovani noveho archivu. To by se dalo delat i pri zavreni souboru, ale to by bylo mene efektivni, protoze by se porad generovaly archivy po kazdem souboru. Na druhou stranu by se snizilo riziko ztraty zmen pri padu systemu nebo necem.

7225

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 31. 08. 2015, 22:06:07 »

Tak on MS mohl udelat neco proto, aby se clovek mene obaval data do kloudu napchat. Data tam mohla jit sifrovana, clovek by si v nejakem onfiguratoru naklikal, ktera se budou sifrovat. Na vsechna zarizeni by si naimportoval klice a bylo by. Sice to neni bombenfest, protoze by se nasli lide, kteri by rekli, ze MS muze krast klice a posilat je do NSA. Ale byla by to aspon jakasi snaha, relativne duveryhodna.

To ovšem vylučuje používání těch dat z webových aplikací, protože ty by ve vašem scénáři zřejmě ty klíče neměly.

Nerikal jsem, ze si naklikam, co se sifrovat ma a co ne?

To jestli je soubor například šifrovaný nebo komprimovaný na úrovni FS nemůžete určovat z obsahu souboru, protože tak vytváříte závislost na něčem co není nikde specifikované a nemáte to pod kontrolou. Například soubory šifrované EFS si můžete vydumpovat v RAW módu (tedy v šifrované podobě) a uložit do souboru; samozřejmě pak nechcete aby vám je FS dešifroval. Navíc stejnou hlavičkou souboru může použít kdokoliv náhodně nebo systematicky. Vizte co jsem psal o záměně ZIP, JAR, KMZ, KWD, ODT, ODP, OTT, SXC, SXD, SXI, SXW, SXC, WMZ, XPI, XPS a XPT (a nejspíš řady dalších formátů). Obsah souboru je prostě věc aplikace, může v něm být cokoliv včetně hlavičky EFS, a FS se podle toho nemůže a nesmí orientovat. Rozdělení na data souboru a metadata má velmi dobré důvody.

Tak ja to nechci urcovat podle obsahu souboru, ale podle jeho hlavicky.

Samozřejmě starší verze FS neumí features novější verze. Tak už to u dopředné kompatibility bývá.

Jiste, nicmene byva zvykem, ze data treba sice neumi precist, ale aspon je nezkurvi. Nyni, kdyz Alois s W 10 prinese flashku Bedrichovi s Widlema 7, aby okopiroval porno pro Cyrila - opet s W 10, tak dojde k tomu, ze si Cyril moc nezaslimta.

MS by teoreticky mohl vydat patch pro starší verze Windows. Těžko ale vydá patche pro kamery, zvuková záznamová zařízení, MP3 přehrávače, televize, mobily, automobily a hromady dalších zařízení.

No, tak kamery asi nebudou sifrovat, tak je to jedno. A kdyby MS zvolil nejaky normalni zpusob znaceni sifrovanych souboru, problem by nebyl ani se zarizenimi z SD.

7226

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 31. 08. 2015, 14:02:27 »

Cloud přináší výhody. Například můžete mít ta samá data přístupná z desktopu, notebooku i telefonu. Samozřejmě k tomu ta data musíte uložit na nějaký server, a to obnáší rizika v oblasti bezpečnosti a ochrany soukromí. Pokud vám taková rizika nestojí za přidanou hodnotu (mě rozhodně nestojí), tak data do cloudu neukládejte.

Tak on MS mohl udelat neco proto, aby se clovek mene obaval data do kloudu napchat. Data tam mohla jit sifrovana, clovek by si v nejakem onfiguratoru naklikal, ktera se budou sifrovat. Na vsechna zarizeni by si naimportoval klice a bylo by. Sice to neni bombenfest, protoze by se nasli lide, kteri by rekli, ze MS muze krast klice a posilat je do NSA. Ale byla by to aspon jakasi snaha, relativne duveryhodna.

Ono neexistuje moc možností, jak to udělat dobře. Můžete jako Jeronýmek spoléhat na to že na nějakém offsetu souboru bude nějaká signature... a pak žehlit problém, až někdo náhodou bude mít soubory (případně rovnou formát souborů) se stejným obsahem na stejném offsetu. Zřejmě vám nedochází, že detekce šifrování souboru v závislosti na signatuře je v principu nespolehlivá. Jenže co čekat od člověka, který by při fsck "pro jistotu" znuloval rezervované bity

Tak jo, predpokladejme, ze dam na disk binarni data, kde zrovna nahodou na zacatku bude kombinace, ktera odpovida hlavicce MS sifrovaneho souboru. No, vzhledem k tomu, ze dneska par bajtu nikdo neresi, co brani MS, aby si za tu hlavicku ulozil napriklad nejakou dalsi znacku (overeni hlavicky), podle ktereho by vznikla temer jistota, ze dat jsou bud binarni bordel nebo sifrovany soubor? Diskety uz nikdo nepouziva, tak treba deset nabo i dvacet bajtu nikoho nezabije. Jaka je pravdepodobnost, ze vytvorim binarni blob, kde treba 20 bajtu bude stejnych? Krome toho v takovem souboru muze byt treba kontrolni soucet nebo se treba pozna, ze to nejde rozsifrovat. A i kdyby, tak pokud MS do toho nebude zasahovat, nic se nestane. Pokud uzivatel neni zretelne blby, tak si vsimne, ze se soubor rozsifroval jako binarni bordel a vzpomene si, ze to neni sifrovany soubor.

Soucasna nova implementace je jaksi znacne suboptimalni. Jak uz bylo vyse poukazano, sifrovane soubory z Widli 10 asi nepreziji kopirovani na jine medium najinem OS, nez W 10. Uzivatel obdrzi medium s binarnim svincikem a bez diskeditoru se k tem datum uz nikdy nedostane. Predstavte si, jak si treba stara Blazkova koupi novou flashku. Tu da spolu se starou vnukovi, at ji prekopiruje data a starou flashku si necha. Vnuk data presype na Macu a puvodni flasku vymaze a prevalcuje pornem. Stara Blazkova pak zjisti, ze nemuze otevrit sifrovane soubory s recepty na babovku a moravske zeli. Nasledne si nasadi brejle, spusti diskeditor a jde to opravovat.

Jak už jsem psal, detekce podle obsahu souboru je v principu nespolehlivá. Pokud se orientujete podle flagu v directory entry, je výsledek jasně daný při zápisu souboru, a nemůže dojít k omylu.

K omylu dojit muze. Potiz je, ze FAT na nejake sifrovani nebyl od pocatku zalozeny a tak k tomu omylu pri trose stesti nemuze dojit pouze tehdy, kdyz vsichni pouzivaji Widle 10. Tak daleko nejsme a jeste nejakou dobu nebudeme. Tady by byvalo vhodnejsi, kdyby si MS prestal hrat na zpetnou kompatibilitu a prisel s novym FATem, ktery neni zpetne kompatibilni. Pro starsi podporovane Widle pak mohl vydat zaplatu, ktera by do nich podporu FATu s sifrovanim dotlacila. Pri trose slusnosti by vytvorili i zaplatu pro XP, protoze do prechodu na kachliky se lidem moc nechce. Pri formatovani na novy FAT by pak user mohl byt upozornen, ze tim ziska sifrovani, ale prijde o moznost cteni sifrovanych souboru na starych Widlich a eventuelne jinych OS. O tuto moznost strjne prichazi a jeste vznika nebezpeci ztraty dat diky nepodpore sifrovani jinde, nez na W 10, kdy clovek pak uz nic neprecte ani na nich.

7227

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 31. 08. 2015, 12:49:58 »

Hlavičky souborů jsou v principu nespolehlivé. To že má soubor na nějakém offsetu pár konkrétních bytů nijak jednoznačně neurčuje jeho typ. To že soubor začíná "Return-Path:" z něj nedělá EML, to že začáná na "SQLite format 3." z něj nedělá SQLite DB file. A například v nešifrovaném souboru .bin můžu mít z mnoha důvodů klidně uložený šifrovaný JPEG ve formátu EFS. Pokud budete používat hlavičky, automaticky ho dešifrujete, a bude to zcela špatně. Podobně můžu mít těch pár bytů, podle kterých byste chtěl rozeznat šifrovaný soubor, náhodou například ve video streamu nebo JPEGu.

To by mne zajimalo, jak to dela utilita file v Linuxu, ze podle hlavicek funguje spise spolehlive, urcite spolehliveji, nez to, co tvrdi Windoze Explorer.

7228

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 31. 08. 2015, 12:33:27 »

To mě zajímá. Jak uděláte transparentní šifrování na FS bez toho abyste měnil on-disk structures? Navíc FAT32 má pro podobné účely rezervované bity a popsané jejich chování, takže ve zvolené implementaci nevidím problém.
[/quote]

Ze byste treba zavedl novou hlavicku souboru, ktera rekne OS, ze se jedna o sifrovany obsah? Zpetna kompatibilita je zarucena. OS, kde to neni implementovano, uvidi jakysi soubor s binarnim bordelem.

7229

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 31. 08. 2015, 11:48:58 »

Tak ta diskuse je posledni dobou hlavne dost monotonni. To je porad ve stylu:

A: Muze za to MS.
B: Muze za to SD.

A k tomu furt ty same argumenty. Chtelo by to prijit s nejakymi novymi, neotrelymi a padnymi argumenty. Treba:

A: Muze za to MS, protoze Bill Gates nosi ruzove slipy.
B: Muze za to SD, protoze manazer zere zabi stehynka.

7230

Windows a jiné systémy / Re:Windows 10 EULA - som zhrozeny

« kdy: 30. 08. 2015, 14:28:20 »

MS ničí uživatelům data, tím to pro mě hasne.

S těmi daty jste trapný, protože chyba je zcela jasně na straně SD, a vaše lež se ani po stovce opakování nestane skutečností.

Jiste, soudruzi z SD udelali chybu. Ale zpusob, jakym MS dobastlil do FATu sifrovani, nepatri k tem nejinteligentnejsim.