Příspěvky

4726

Server / Re:Protokol mezi proxy a backendem

« kdy: 07. 11. 2015, 21:58:44 »

Protokol HTTP/2.0 nemá povinné šifrování. Pokud mezi proxy a backendem je bezpečná síť, je to jeden z mála případů, kdy dává smysl použít nešifrované HTTP.

Jinak je samozřejmě lepší mezi proxy a backendem použít HTTP/2.0 – jednak tak můžete využít novinky HTTP/2.0 i pro komunikaci s klientem (třeba server push – je lepší to řešit na backend serveru, než přidávat logiku na proxy), jednak z toho mohou těžit i HTTP/1.1 klienti (díky server push může mít proxy server příslušný soubor už v cache, až o něj klient požádá).

4727

Server / Re:Zálohování po pomalé lince

« kdy: 06. 11. 2015, 15:08:16 »

Tak to budeš psát přesně ten unison, akorát ten navíc finálně synchronizuje algoritmy rsyncu.

Takže pokud se spustí nad WebDAVem připojeným jako disk, bude se ten soubor přenášet mnohokrát sem a tam.

Myslím, že ta „pomalá linka“ v názvu tématu je součástí zadání, není to cíl, ke kterému se snažíme dojít, ať už bude původně linka jakkoli kapacitní…

4728

Server / Re:Zálohování po pomalé lince

« kdy: 06. 11. 2015, 14:48:56 »

Z meho pohledu je uplne jedno, jestli je to webDav nebo samba share. Proste je to namapovane bud jako disk s pismenkem ve Windows nebo jako adresar ve filesystemu v Linuxu. Pro zalohovaci aplikaci je to transparentni - proste zalohuje z jednoho adresare (rychleho) do druheho (pomaleho).

Předpokládám, že SMB umožňuje zapisovat i do části souboru – že můžete na server poslat příkaz „přepiš bajty 10–20 tímhle: …“. To u WebDAVu nejde, tam musíte vždy zapsat celý nový soubor. To je z hlediska zálohování dost podstatný rozdíl, a dost podstatně to ovlivňuje i tu síťovou komunikaci, která se bude dít pod tím namapovaným diskem.

Sitovou komunikaci resit nepotrebuju, pro aplikaci to jsou jen dva adresare. Zaroven mi to bude fungovat nezavisle na tom, jake vzdalene uloziste si namapuju do filesystemu.

S tímhle přístupem ale riskujete, že budete mít síťové přenosy násobně větší, než kdybyste se síťovou komunikací zabýval. Zvlášť pokud mapujete WebDAV jako klasický disk, hrozí, že se ty soubory budou opakovaně přenášet sem a tam, přestože by stačilo nahrát na server novou verzi nebo dokonce data souboru vůbec nepřenášet.

Použít takové řešení samozřejmě můžete, ale není to řešení vhodné pro pomalou linku, naopak je to řešení pro případ „nebudu nic vymýšlet, na optice je spousta volného pásma“.

4729

Vývoj / Re:Kde / v čem programujete JS?

« kdy: 05. 11. 2015, 15:39:01 »

JetBrains IntelliJ IDEA, pro JavaScript stačí WebStorm. Se složitostí skriptu vám ale nepomůže žádné IDE, tam je podstatná organizace zdrojového kódu a modularizace. Já preferuju pro web Dojo, tedy modularizaci pomocí AMD. Případně verze ES6, pokud ji můžete použít, má podporu pro moduly už zahrnutou ve standardu jazyka – je to trochu něco jiného než AMD.

4730

Server / Re:Zálohování po pomalé lince

« kdy: 05. 11. 2015, 14:36:45 »

ad rychlost linky, prenos atributu atd.: Mam vyzkouseno, ze jen seznam souboru muze mit treba 50MB (a to je bez timestampu). A kdyz se zmeni jen par set kB, tak napr. po 1MBit UPC upload lince to je dost podstatny rozdil.

Přičemž v tom postupu, který jsem popsal, se žádný seznam souborů nepřenáší.

4731

Server / Re:Zálohování po pomalé lince

« kdy: 05. 11. 2015, 10:48:14 »

Jde nejak presvedcit Unison/Rsync aby zkopiroval pouze tyto soubory?

Jestli nic takoveho neni, tak to beru a muzu si to napsat sam.

-----
pro vsechny lokalni soubory udelat
-- vzit soubor, spocitat CRC a zapsat do databaze spolu s atributy souboru, nazvem a cestou

pro vsechny zaznamy v databazi
-- pokud je neexistuje soubor drive nebo se zmenil CRC, zkopirovat do vzdaleneho disku
-- pokud soubor drive existoval a ted uz ne, smazat z vzdaleneho disku
-----

Pokud je to vzdálené úložiště WebDAV, nepoužívejte nad tím žádný Unison nebo Rsync, tím to akorát komplikujete a zpomalujete. Použil bych následující postup:

• vytvořit časovou značku pro příště
• vytvořit seznam souborů pro příště
• přes find -newer najít soubory, které se od minulé časové značky změnily
• nalezené soubory přímo přes WebDAV zkopírovat na vzdálené úložiště
• vytvořit aktuální seznam souborů a porovnat jej s tím dříve uloženým – soubory, které na novějším seznamu oproti minulému chybí přes WebDAV ze vzdáleného úložiště smazat

Jediné zbytečné kopírování, které v tomhle režimu může nastat, je v případě, kdy se soubor změní mezi vytvořením časové značky a vlastním kopírováním – v takovém případě se příště bude kopírovat zbytečně znovu. Předpokládám, že zálohu budete stejně dělat v době, kdy je pravděpodobnost změny souboru nízká, takže bych to neřešil. (Z tohohle důvodu je potřeba dělat časovou značku před začátkem kopírování – kdybyste ji dělal až na konci, nebudete mít v žádné záloze změny, ke kterým došlo během zálohování).

4732

Server / Re:Zálohování po pomalé lince

« kdy: 05. 11. 2015, 10:23:09 »

Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.

Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.

4733

Server / Re:Zálohování po pomalé lince

« kdy: 05. 11. 2015, 10:05:20 »

Kdyz vim, ze jsem jediny, kdo soubory na vzdalenem disku modifikuje, tak nepotrebuju, aby pokazde probihala kontrola znovu. Stejne vrati ten samy vysledek jako minule. Stacilo by mi si zapamatovat vysledek kontroly jednou a pouze upravovat dilci data, kdyz se tam ode mne synchronizaci priadji nove nebo zmenene soubory.

Když víte, že jste jediný, kdo soubory modifikuje, nemusíte si u souborů pamatovat vůbec nic, protože datum modifikace souboru si pamatuje souborový systém. Takže si zapamatujete jenom datum a čas, kdy jste naposledy prováděl zálohu, a pak zkopírujete jenom novější soubory. Jediná nevýhoda je, že se takhle nebudou v záloze mazat lokálně smazané soubory. Pro nalezení změněných souborů použijte find -newer případně find -mmin.

4734

Server / Re:Zálohování po pomalé lince

« kdy: 05. 11. 2015, 08:52:44 »

na Widlich pri zalohovani pres sdileni

V takovém případě se ale nepoužívá ta hlavní přednost rsyncu a rsync bych do toho tím pádem vůbec nemotal, je to akorát matoucí. Pište o tom raději jako o cp -ru, bude to mnohem přehlednější.

4735

Server / Re:Zálohování po pomalé lince

« kdy: 05. 11. 2015, 08:27:21 »

On ma a nema pravdu. Vede to k tomu, ze rsync si mysli, ze se jedna o jiny soubor, protoze nesedi timestamp a tak rsync pokazde soubor rovnou kopiruje, i kdyz nebyl zmenen (odtud zpomaleni).

Při použití přes síť rsync ve výchozí konfiguraci nekopíruje celý soubor, ale pomocí kontrolních součtů bloků zjistí, které části se změnily, a přenese pouze ty. To je ta nejdůležitější vlastnost rsyncu, proto vznikl. Změnou zaokrouhlování rsyncu se tedy ušetří jenom ten výpočet a přenos kontrolních součtů. Také je to úspora, ale mnohem menší než úspora kopírování celého souboru.

4736

Server / Re:Zálohování po pomalé lince

« kdy: 04. 11. 2015, 23:25:57 »

Přes WebDAV je možné přenášet různé atributy souborů. Nejspíš mezi nimi bude datum a čas poslední modifikace souboru, může tam být také hash. Můžete pak porovnat datum a čas poslední modifikace, případně také hash souboru, a soubor zálohovat jenom tehdy, pokud se změnil. Přenášení pouze změněných částí by musel WebDAV server podporovat pomocí nějakého rozšíření protokolu.

4737

Server / Re:Webhosting zdarma s SSL a SNI

« kdy: 02. 11. 2015, 15:39:37 »

Endora program Plus za 17 Kč měsíčně, levnější neznám.
http://www.endora.cz/vlastnosti

U Wedosu může mít s tím tarifem MiniWeb SNI certifikát za 12 Kč s DPH měsíčně. Ale řešíme tu nesmyslné částky, navíc tazatel zjevně chce něco jiného, než napsal, protože „učit se“ (ať už to znamená cokoli) SSL s SNI  může klidně na svém počítači, k tomu nepotřebuje žádný webhosting.

4738

Software / Re:podepsání PDF na serveru

« kdy: 02. 11. 2015, 12:55:08 »

pouzivame presne na tohle s uspechem jsignpdf http://jsignpdf.sourceforge.net/

To voláte na serveru z PHP?

4739

Software / Re:podepsání PDF na serveru

« kdy: 02. 11. 2015, 10:26:07 »

Nedávno se tu podpis PDF v PHP řešil: Digitální podpis PDF v PHP.

4740

Software / Re:podepsání PDF na serveru

« kdy: 02. 11. 2015, 09:27:37 »

Zaručený elektronický podpis nemůžete použít, ten podle zákona vyžaduje, aby se podepisující osoba seznámila s tím, co podepisuje. Pokud podepisuje automat, můžete použít elektronickou značku. Jenže pak je zase otázka, zda to bude akceptovat protistrana.