Příspěvky

4801

Sítě / Re:Přesměrování provozu na firemní proxy

« kdy: 02. 09. 2015, 06:49:00 »

Můžete na proxy server přesměrovat veškerý odchozí provoz na port 80. Ale pokud nějaký web poběží na jiném portu, přesměrování to nezachytí. Také takhle nejde přesměrovat HTTPS, protože tam se komunikuje jiným způsobem přímo s cílovým serverem a jinak s proxy serverem.

4802

Odkladiště / Re:Email jako důkaz pro soud

« kdy: 01. 09. 2015, 19:15:13 »

A dál by mě zajímalo, pokud se to tedy dá i takhle zfalšovat, co proti tomu dělat? Můžu používat nějaký digitální podpis, GPG klíč, nebo nevim? Ale když to nebude používat protistrana, jejíž emaily asi jsou ty, co mě zajímají, tak si nepomůžu. Nebo je nějaký způsob?

Podepisovat elektronickým podpisem založeným na uznávaném certifikátu, a vyžadovat totéž od protistrany. Pak ten podpis musí každý v EU uznávat stejně, jako uznává vlastnoruční podpis. (Což neznamená, že ho opravdu každý uznává, ale u soudu by s tím nepochodil.)

4803

Server / Re:Postfix - jedna doména, 2 lokality, 3 servery

« kdy: 15. 08. 2015, 14:11:37 »

Pokud byste uživatele měl v nějaké databázi (třeba LDAP), musíte řešit její replikaci. Pokud byste měl databázi jenom na jednom místě, výpadek dané lokality by vám odstavil všechny tři servery.

Pokud uživatelů není mnoho, zapsal bych si do jednoho souboru uživatele s příznakem, ve které jsou kanceláři, do druhého souboru seznam distribučních skupin s uživateli, a pak bych si napsal skript, který podle těch souborů vytvoří konfigurační soubory pro všechny tři lokality a rozkopíruje je na příslušné servery.

4804

Hardware / Re:Co se děje při přejmenování souboru?

« kdy: 15. 08. 2015, 13:56:56 »

Tohle možná platí u některých FS, ale třeba u EXT2/3/4 to neplatí: Data jsou zvlášť, metadata jsou zvlášť a názvy souborů v adresářích jsou také zvlášť.

Některé souborové systémy (např. ReiserFS) zase ukládají data malých souborů přímo do metadat. To jsou ale implementační detaily. Podstatné je to, že uložení dat na disku nevypadá tak, že by byl uložen adresář, v něm název souboru, pak jeho data, pak název dalšího souboru v adresáři, zase jeho data atd. Takže když se přesouvá soubor v rámci jednoho souborového systému, obsah souboru (obvykle) zůstává na svém místě a šíbuje se jen s metadaty.

4805

Hardware / Re:Co se děje při přejmenování souboru?

« kdy: 15. 08. 2015, 13:09:53 »

Metadata o souborech (název, velikost, datum vytvoření, oprávnění atd.) jsou v souborovém systému uložena zvlášť, samotná data souboru také zvlášť. A adresář je v unixových systémech jenom zvláštní typ souboru, který v datech má uložen seznam souborů (tj. i adresářů), které jsou v něm. Takže někde na disku je uložen seznam souborů v adresáři A, a v tom seznamu je uvedeno například "soubor se jmenuje X, byl vytvořen tehdy a tehdy, vlastníkem je uživatel U, samotná data souboru začínají na disku na pozici P a soubor je dlouhý S bajtů". Takže když soubor přesouváte v rámci jednoho souborového systému, vezme se tenhle záznam a přesune se do jiného adresáře - se samotnými daty na disku se ale nijak nehýbe.

Tolik ten nejjednodušší popis, ve skutečnosti je to komplikovanější - např. data souboru nemusí být uložena souvisle, takže tam nebude jen "začíná na pozici P", ale musí tam být seznam, kde jsou jednotlivé části. A dále ve skutečnosti není v adresáři přímo odkaz na ten soubor, ale je tam jen jeho jméno a odkaz na tzv. inode, což je unikátní číslo souboru v rámci souborového systému. A těch odkazů na jeden inode může být víc (to jsou v unixu pevné odkazy, hardlinky - víc názvů souboru odkazuje na jeden inode a tedy na jeden soubor). Ty odkazy na inody nemusí být jen v souborovém systému, může je mít třeba také aplikace v paměti. A když zanikne poslední odkaz na inode, přestane daný soubor být dosažitelný a operační systém si místo, které zabírala jeho data, označí jako volné. Takže když přejmenujete soubor na jméno jiného existujícího souboru, smaže se v adresáři ten záznam se jménem, který odkazuje na nějaké inode, a místo něj se vloží nový, se stejným jménem, který odkazuje na inode toho přejmenovávaného souboru. Pokud byl ten původní odkaz na soubor poslední, ten původní soubor se smaže. Je ale možné, že na ten soubor odkazoval ještě jiný záznam v souborovém systému, pak bude ten původní soubor dostupný pod tímto jiným jménem. Nebo ten soubor mohla mít otevřený nějaká aplikace, pak pro ni bude stále dostupný, až do uzavření toho souboru nebo ukončení aplikace. A také může nastat případ, že ten soubor už nebyl dostupný z jiného adresáře, ale pouze byl otevřený v aplikaci - takže pro všechny jakoby zmizel a zůstává viditelný jen pro tu aplikaci. Ta aplikace ale může zase do nějaké adresáře zapsat odkaz na ten soubor, a tím se ten soubor zase "objeví" i pro ostatní.

Pokud soubor přesouváte na jiný souborový systém, soubor se nejprve zkopíruje a na konci se ten původní smaže. (Jak plyne z předchozího, kopírovací aplikace by si ho mohla nejprve otevřít, pak smazat a pak teprve kopírovat - dokud by jej měla otevřený, může z něj pořád číst a k jeho fyzickému smazání nedojde. Jenže pak by hrozilo, že se něco pokazí, aplikace například havaruje, a pak byste původní soubor neměl a v cílovém souborovém systému by byla jen jeho část.)

4806

Vývoj / Re:Pomoc při sestavení xml path pro XmlDocument v .NET

« kdy: 13. 08. 2015, 07:16:14 »

Elementy session-factory a property jsou také ve jmenném prostoru urn:nhibernate-configuration-2.2. Takže XPath má být x:hibernate-configuration/x:session-factory/x:property[@name = 'connection.connection_string']

4807

Software / Re:WinSCP WebDAV - WinSCP kazi uzivatelske jmeno

« kdy: 29. 07. 2015, 23:06:34 »

Ani jsem nevěděl, že WinSCP už umí i WebDAV...

Nezdá se mi ten údaj v "Hostitel" - podle mne by tam mělo být jenom doménové jméno serveru.

4808

Server / Re:Kolik VPS na fyzickém serveru

« kdy: 28. 07. 2015, 19:53:10 »

Skoro kazdy server alokuje ku kazdej poziadavke nejaku RAM. Tie GB RAM nemusia byt treba v jednom okamziku, len sa proste na to GC vykasle, ked je este z jeho pohladu volna pamat.

Takže JVM alokuje paměť až do maxima, které má povoleno. To mi nepřipadá jako chybné chování. Chybné by naopak bylo dělat zbytečně GC, když je paměti dost.

4809

Server / Re:Kolik VPS na fyzickém serveru

« kdy: 26. 07. 2015, 15:17:15 »

O Jave to plati dost kvoli aplikaciam, ale nie iba kvoli nim. Je to o tom, ako fungoval garbage collector v pouzivanych implementaciach.
Java alokuje pamat od OS a dojde na iste maximum. Neskor sa sice pamat nepotrebuje, GC ju oznaci ako volnu, lenze niektore GC ju potom nevracali OS. Vdaka tomu Java program nemal problem zozrat gigabajty RAM.

Donedavna sa pouzival ekvivalent dnesneho -XX:+UseParallelOldGC a ten prave v defaulte neuvolnoval (mozno stale neuvolnuje) pamat OS.

To ale popisujete aplikaci, která v určitém okamžiku potřebuje ty gigabajty RAM, ale pak už je přestane potřebovat a dál by si vystačila s mnohem menším paměti. Kolik takových aplikací asi bude, zvlášť na VPS? Navíc když už ta aplikace paměť nepotřebuje, bude akorát zabírat místo ve swapu - to není žádná tragédie. Jistě, není to optimální zacházení s pamětí, ale jak často to přináší problémy? Na druhou stranu, každá JVM aplikace má strop, kolik maximálně paměti může spotřebovat (s výjimkou alokací mimo heap, které používá jen málo aplikací) - kolik jiných aplikací takovou možnost má?

4810

Odkladiště / Re:Prodej mého software bez souhlasu

« kdy: 22. 07. 2015, 10:43:51 »

Můžete na tu firmu rovnou podat trestní oznámení, nebo je můžete zatím jen upozornit. V obou případech by to ale chtělo právníka, rozjet něco na vlastní pěst a pak chtít po právníkovi, ať vás tahá z bryndy, není moc dobrý postup.

Především si ale nejprve zkontrolujte svou vlastní licenci. Opensource varainta Magenta je šířena pod licencí OSL 3.0. Vaše rozšíření je s největší pravděpodobností odvozenou prací, u které OSL 3.0 vyžaduje zachování licence - tedy i vaše rozšíření by mělo být pod licencí OSL 3.0. A pak by ta firma měla právo vaše rozšíření dál upravovat a šířit.

4811

/dev/null / Re:Proc neni linux za penize

« kdy: 17. 07. 2015, 20:21:38 »

V době, kdy Linux začínal, nikdo netušil, že takhle uspěje. Linus s tím začal jenom proto, že si to chtěl vyzkoušet - nebylo to myšlené jako výdělečný projekt. Pro rozvoj bylo důležité to, že ostatní mohli s minimálními náklady navazovat. Kdyby byl Linux na začátku za peníze, byla by to bariéra, a místo něj by se pravděpodobně rozšířil jiný systém.

Navíc současný Linux je dílem stovek vývojářů, takže i kdyby byl placený, rozhodně by na něm nevydělával jen Linux. Jinak Linuse (a spoustu dalších vývojářů) zaměstnávají linuxové firmy, takže on peníze z Linuxu má, i když to není přímo za prodej licencí.

4812

Sítě / Re:Ubiquiti / UniFi - administrace bez Java

« kdy: 17. 07. 2015, 07:04:35 »

Ovladaci sw jde spustit pres wine ... nevidim problem.

Takže nefunguje na jedné, ale na dvou platformách. To je výrazné zlepšení...

Patrne nespravujete desitky zarizeni, podle toho Vas prispevek vypada.

Mně připadá lepší desítky zařízení spravovat v jednom programu než každé zvlášť přes webové rozhraní, ale ať si to každý dělá jak chce.

4813

Vývoj / Re:MySQL - jedna velká tabulka, nebo mnoho malých

« kdy: 16. 07. 2015, 19:14:22 »

Podle vašeho popisu soudím, že ty záznamy mají stejnou strukturu - pak je samozřejmě lepší mít je v jedné tabulce. Pokud je objem dat velký, řeší se to prostředky databáze pomocí tzv. partitions - podle vámi definovaných pravidel si databáze sama rozdělí velkou tabulku na několik menších. Vy s ní dále můžete pracovat jako s jednou velkou tabulkou, ale pokud se dotazujete na data, která leží pouze v jedné nebo několika partition (a databáze to z vašeho dotazu pozná), bude pracovat jenom s příslušnými částmi.

4814

Sítě / Re:Ubiquiti / UniFi - administrace bez Java

« kdy: 16. 07. 2015, 19:09:40 »

Pokud byste ta zařízení chtěl vyhodit, já si je vezmu - poradím si s nimi, já žádnými předsudky vůči Javě netrpím.

Pokud se bojíte o bezpečnost, neinstalujte Java plugin do prohlížeče, a máte to vyřešené. Ona se Java v prohlížeči sice nespustí sama od sebe a vyžaduje schválení uživatelem, ale možná ti vaši technici odkliknou každé okno, které jim prohlížeč zobrazí.

Nebo můžete používat Mikrotiky, ty mají ovládací software pouze pro Windows, třeba vám to bude vyhovovat lépe než multiplatformní Java. A pokud chcete něco naklikat jenom na jednom zařízení, mají Mikrotiky dokonce už i použitelné webové rozhraní (ale to mají Ubiquity také a podle mne o dost lepší).

4815

Vývoj / Re:Výpis IPv4 i IPv6 adresy v php

« kdy: 15. 07. 2015, 21:49:07 »

Nijak, nejde to. Na server máte navázané TCP/IP spojení z nějaké IP adresy (což ani nemusí být adresa klienta, může to být proxy server nebo NAT). To, že zařízení s danou IP adresou má nastavené také jiné IPv4 nebo IPv6 adresy na straně serveru žádným způsobem nezjistíte.

To, zda je upřednostňován IPv6 protokol, je věc konfigurace klienta. Podle RFC by to tak tuším mělo být, ale má to tak myslím jen 80 % klientů, kteří mají IPv6 konektivitu.