Příspěvky

3676

Vývoj / Re:HTML + Java Autocomplete

« kdy: 30. 10. 2017, 12:50:35 »

nechce sa mi celkom verit ze na to potrebujem az taky kanon.
Neviete niekto poradit nieco viac easy ?

Ono především není jasné, co vlastně chcete. V titulku máte uvedenou Javu – proč? V dotazu pak o ní nic není. Nebo si pletete Javu a JavaScript?

Jinak to, co popisujete, je triviální kód na tři řádky. Na inputu 1 si pověsíte na událost onchange volání funkce, ve které nastavíte hodnotu inputu 2. Pro mapování hodnot použijete standardní JavaScriptový Object, který se chová jako mapa, hashovací tabulka – obsahuje klíč (očekávanou hodnotu input 1) a hodnotu (hodnotu, která se má nastavit do input 2).

3677

Sítě / Re:UPC IPv6 DS-Lite

« kdy: 30. 10. 2017, 00:34:43 »

JÁ mám, sakra, na starosti firemní VPN server... 

Tak si, sakra, nejdřív zjistěte, v čem je problém. A pak s tím konkrétním problémem v konektivitě můžete jít za UPC. Pokud to tedy bude chyba UPC – pořád ještě to také může být chyba vaší konfigurace (já bych to dokonce považoval za pravděpodobnější). UPC může řešit problémy s konektivitou, ale nebude vám řešit vaše problémy s vaší VPN.

3678

Vývoj / Re:Synchronizace - obrácený semafor

« kdy: 29. 10. 2017, 19:10:17 »

Třída, která umí jen snižovat, se v Javě jmenuje CountDownLatch. Obecně pak funguje Phaser. Zda to má i nějaké obecné názvy nevím.

3679

Server / Re:Připojení k proxy přes SSL

« kdy: 27. 10. 2017, 13:35:48 »

Pro přihlášení k proxy můžete použít autentizační mechanismy, které nepřenášejí citlivé údaje v otevřeném tvaru. Například v případě Squidu můžete využít Digest autentizaci, NTLM, SPNEGO (tedy Kerberos) a OAuth. Dál už nevadí, že je komunikační kanál s proxy nešifrovaný, protože šifrovaná by měla být komunikace, která tím kanálem teče – tedy měl byste používat HTTPS. Pokud použijete HTTP, nemá moc smysl hrát si na to, že komunikaci s proxy zašifrujete, protože z proxy serveru dál už to stejně půjde nešifrovaným HTTP.

3680

Sítě / Re:UPC IPv6 DS-Lite

« kdy: 27. 10. 2017, 10:53:58 »

Řekl bych, že úroveň odpovědi odpovídá úrovni dotazu…

Pochybuju, že UPC je váš poskytovatel VPN služeb – pouze vám poskytuje internetovou konektivitu. Pokud vám nefunguje firemní VPNka, musíte to řešit s firemními správci. Že by byl problém na straně poskytovatele konektivity je dost nepravděpodobné.

3681

Sítě / Re:SSH s Putty cez firemné HTTP proxy

« kdy: 26. 10. 2017, 14:37:05 »

V případě té http(s) proxy, bych se snad i vsadil, že to nemůže fungovat, alespoň na opravdové, chytré a cachovací proxy jako mám u svého zaměstnavatele já.

Žádná HTTPS proxy neexistuje. Existuje pouze HTTP proxy, která umožňuje pomocí HTTP metody CONNECT přes proxy navázat tunelované spojení, kterým je možné přenést libovolný jiný protokol – obvykle HTTPS, ale klidně i to SSH. Opravdová HTTP proxy to umí, chytrá proxy může být omezená na cílový port 443, ale tazatel psal, že SSHD mu běží i tam. Chytrá proxy se taky může pokoušet z charakteru provozu a případně provozních dat posílaných před začátkem šifrovaného spojení určit, zda tím šifrovaným kanálem protéká opravdu HTTPS nebo něco jiného. Cachovací proxy cachuje jen HTTP provoz, do HTTPS nevidí.

3682

Sítě / Re:SSH s Putty cez firemné HTTP proxy

« kdy: 25. 10. 2017, 12:43:36 »

Když v PuTTY nastavujete konfiguraci spojení, zvolte si ve stromečku voleb Connection → Proxy, Proxy type nastavte na HTTP a zadejte adresu a port proxy. Ovšem pokud je ta proxy nastavená tak, aby navazovala spojení jenom na cílový port 443 nebo jiné vybrané, nebude vám to fungovat.

Přes HTTP proxy Vám jiný protokol, než je HTTP nebo HTTPS nepojede.

Ale pojede, HTTPS je šifrované spojení, takže HTTP proxy dovnitř nemůže vidět. HTTPS spojení se přes HTTP proxy navazuje tak, že klient zavolá metodu CONNECT a specifikuje cílovou adresu a port, kam se chce připojit. A proxy jenom naváže spojení a vytvoří tak tunel, kterým se posílají data mezi klientem a cílovým serverem. Jestli ta data patří protokolu HTTPS nebo SSH by se dalo zjišťovat nějakou heuristikou, ale není to něco, co by proxy rovnou viděla.

3683

Server / Re:Apache: promenna ze skriptu

« kdy: 24. 10. 2017, 14:51:06 »

Neexistuje. Lze pouze předgenerovat celou konfiguraci nějakým scriptem a tu celou načíst.
Lze to např. udělat vždy do nezávislého adresáře, a apache načíst z té aktuální konfigurace po proběhnutí configtestu.

Případně lze pomocí Include či IncludeOptional vložit jiný konfigurační soubor, ve kterém může být jen ta jedna direktiva, kterou je potřeba změnit. Pořád se ale vkládá statický soubor, který je potřeba případně správně vytvořit před startem Apache nebo přenačtením konfigurace.

3684

Studium a uplatnění / Re:Domena pre vlastny web? (resume)

« kdy: 24. 10. 2017, 12:05:22 »

Pro osobní stránky se spíš používá .name, nakonec je to i levnější. Doména .me je národní doména Černé Hory, což může být někdy matoucí, teoreticky může mít nějaká pravidla, kdo si ji může zaregistrovat. A nepřipadá mi to zas tak vtipná kombinace, aby stálo za to tu doménu takhle „zneužívat“. Tím .name byste podle mne dal víc najevo, že je to vaše osobní stránka, a také je tam myslím menší pravděpodobnost nedorozumění (že někdo nepochopí, že jde o doménu, nebo když to budete používat v českém prostředí a diktovat, že to někdo pochopí jako „mě“, „mne“, „mi“ apod., dle výslovnosti). Z hlediska porozumění v ČR/SK prostředí ale bude nejlepší doména .sk nebo .cz, ta druhá by vás vyšla ještě o dost levněji.

Doména jen pro umístění životopisu mi připadá trochu málo, to můžete dát třeba na Dropbox nebo Google Drive, pokud to neumí přímo LinkedIn. Ale dost lidí má takhle osobní prezentaci, mají na té doméně i e-mail atd.

3685

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 24. 10. 2017, 07:24:46 »

Otazkou ale je, jak zalohovat, aby se odhalily chyby v datech pri zalohovani a ta chyba se nesirila dal.

Jestli to chápu dobře, máte někde nějaké pracovní soubory, o kterých „víte“, že jsou správné – případně ty pracovní soubory udržujete ve více kopiích, které můžete porovnat. Pak z nich uděláte TC kontejner a ten chcete zálohovat.

Spočítejte si hashe těch souborů a přidejte je do toho TC kontejneru, pak spočítejte i jeho hash. Vytvořený TC kontejner přeneste na jiné zařízení, tam ověřte jeho hash, znovu rozbalte TC kontejner a zkontrolujte hashe vložených souborů. Tím budete mít jistotu, že TC kontejner je vytvořen správně a jde rozbalit. Pak už jenom ten TC kontejner s hashem zazálohujte – nejbezpečnější je uložit to u dvou poskytovatelů cloudového úložiště (akorát je potřeba si ohlídat, aby ve skutečnosti nepoužívali stejnou infrastrukturu). Pokud chcete mít jo jistotu, že se k datům dostanete, i když dojde k nějaké katastrofě a přestane existovat internet, rozdělte ten TC soubor na 5 částí a ty vypalte na DVD, která můžete uchovávat klidně u sebe, ale hlavně musíte pravidelně ověřovat, že soubor na nich není poškozený.

3686

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 23. 10. 2017, 21:44:34 »

Ano, to ovsem zavani nikoliv nejakym lepsim DropBoxem od Amazonu, ale VPS, kam nahraju soubor, pustim vdaleny terminal s Linuxem a necham si spocitat hash. Pokud to tedy nechcete pokazde tahat zpet a overovat lokalne. Otazka za sto bodov: Umi Amazon - jak se to jmenuje - poskytnou terminal anebo jen ten lepsi DropBox?

Ten hash si nemusíte počítat sám, může ho počítat provozovatel úložiště – je to i v jeho zájmu. Při nahrávání souboru na Amazon Glacier povinně posíláte i hash souboru, podle kterého si Amazon zkontroluje, že mu dorazila ta správná data.  Při stažení souboru vám hash pošle. V OpenStack Object Storage API je při uploadu volitelná hlavička ETag, kde je alespoň MD5.

Když chcete dokázat, že nějaké řešení je nepoužitelné, nedokazujte to na tom, jak byste to udělal co nejhloupěji, ale zkuste si zjistit, jak se to v praxi doopravdy dělá.

3687

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 23. 10. 2017, 20:23:49 »

Ano, dobry napad, ktery trpi jednim zadrhelem. Kdyz pri prenosu teto jedne zalohy vznikne chyba, bud tato nasledne rozkopirovana o vsech dalsich kopii.

Tento drobný zádrhel byl vyřešen už s vynálezem otisků souborů a jejich ověřování. O tom, jak správně ověřit obsah souboru, se tu vedla debata asi tak na devíti stránkách.

3688

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 23. 10. 2017, 18:29:46 »

Pokud by to ale trvalo cely vikend, tak by cely vikend ten kontejner nemohl otevrit, coz muze vadit.

Lokální kopie dat se dá samozřejmě udělat mnohem rychleji a odesílá se potom ta.

A i kdyby nevadilo, tak by to znamenalo, ze by zalohoval akorat 1x tydne, coz ja bych u tak krute dulezitych dat nedelal.

Tazatel psal o frekvenci zálohování jednou za dva až tři týdny. Pokud byste chtěl na offline média zálohovat častěji, než jednou týdně, opravdu byste nedělal nic jiného, než pořád jen rozvážel média.

Tohle by mohl zachranit jedine vzdaleny stroj s rsyncem, aby se zalohovalo jen to, co se zmenilo, respektive zmenene bloky

O charakteru dat nic nevíme – zvlášť, když je to šifrovaný disk, klidně je možné, že bude celý soubor pokaždé úplně jiný.

pokazde rvat 20 GB a navic nekolikrat do nekolika mist

Což není nutné dělat přes ten předpokládaný pomalý upload, stačí to dostat ven jednou. Samozřejmě záleží na konkrétní službě, ale je dost možné, že by ani nebylo potřeba mít vlastní zprostředkující server, že by stačilo nahrát to na jednu službu a odsud rozdistribuovat kopie do dalších míst.

3689

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 23. 10. 2017, 13:34:32 »

Vetsina lidi ma doma nejake ADSL a to miva dosti trapnou sirku pasma smerem ven.

Ovšem většina lidí nepotřebuje z domova zálohovat 20 GiB data na čtyři různá místa minimálně ve dvou státech, protože nezálohují z domova výsledky vědeckého výzkumu, ve kterém jsou desetitisíce hodin práce.

Ostatně, když se to zálohování nedělá ručně, ale automaticky, nijak nevadí, pokud se doba uploadu pohybuje v hodinách – ten automat opravdu není netrpělivý a klidně to tam může nahrávat celou noc nebo celý víkend.

3690

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 22. 10. 2017, 20:29:58 »

Bylo by. V případě, že krabička na konci toho drátu bude končit v něčem inteligentním s veřejnou IP adresou a takovou konektivitou, že nebude tetička půl dne bez seriálů po VoD. Pak není problém mít u příbuzných NASy s filmama, písničkama a fotkama a třeba 10% si po domluvě rezervovat za to, že se jim o to (na dálku) stará.

Ale ve světě "krabiček za tři stovky", když ISP umí jenom IPv4 za CGNATem po 5GHz WiFině je vožení FLASH disků autem menší opruz.

A ještě nesrovnatelně menší opruz je nahrát to k nějakému poskytovateli služby úložiště. Pak tam jsou i nějaké definované záruky a nezáleží to na tom, že syn tetičky bude potřebovat na NASu uvolnit místo, aby se mu tam vešel nejnovější díl Ovečky Shaun, tak trochu promázne nepotřebné věci (včetně té superdůležité zálohy).