Příspěvky

1546

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 15:46:00 »

Když nás takových bude víc, třeba autoři OpenWRT pochopí, že není ani rok 1998 ani 2038 a že je potřeba se s veřejnými doménami směřujícími na privátní IPv4 adresy smířit.

To podle mě není dobré řešení. Přebíjet DNS odpovědi je "nebezpečné" - ve smyslu hledání problémů. Na takové řešení si po roce už nikdo nevzpomene a pak se obvykle v síti honí duchy.

Daleko lepší je dotaz na routeru, i za cenu více router-cyklů přechroustat SNATEM i DNATEM - tedy cíl přepsat DNATEM z veřejné IP adresy na privádní, a zdrojovou (aby se navrátila odpvěď) přepsat SNATEM naopak na veřejnou IP adresu routeru.

Pokud tedy máme:
10.0.0.45 (klient PC)
10.0.0.10 (server v privátním rozsahu)
10.0.0.1 (privátní IP routeru)
184.47.23.3 (veřejná IP routeru a zároveň veřejná IP serveru (NAT))


Takže z požadavku:
10.0.0.45 (klient) => 184.47.23.3 (server)
se v prvním kroku provede DNAT:
10.0.0.45 (klient) => 10.0.0.10 (server - privátní)
a v druhém kroku (kvůli zpětné cestě přes router, kvůli RP filtru)
10.0.0.1 (router-privátní) => 10.0.0.10 (server - privátní)

Takže požadavek bude:
10.0.0.45 => 184.47.23.3(<=DNAT+SNAT=>)10.0.0.1 => 10.0.0.10
a odpověď bude:
10.0.0.10 => 10.0.0.1 => 10.0.0.45

1547

Distribuce / Re:CentOS dependency hell

« kdy: 11. 06. 2018, 22:20:55 »

disablovat postgres repo jsem samozřejmě zkoušel jako první. Vůbec k ničemu to není. I kdyby to byla chyba postgresu, pořád to ukazuje na to, jak hloupý ten YUM vlastně je. Žádnou pomoc typu varianta 1 - ponechat knihovnu nastávající verzi / varianta 2 - vyhodit závislý balíček pryč nenabízí.

RHEL (a tím pádem i CentOS) jsou založené na tom, že nemáte mít žádná externí repo. U RHEL jste v tu ránu bez podpory a instalace ztrácí svoji hodnotu. Je tedy poměrně logické, že žádnou alternativu k tomu nenabízejí.

Pokud potřebujete novější balíky a nejde Vám o podporu (případně klonovanou stabilitu), pak bych raději volil úplně jinou distribuci.

1548

Odkladiště / Re:Nesvobodný open-source - jakou použít licenci?

« kdy: 11. 06. 2018, 18:25:24 »

O to v téhle diskusi jde, jakou licenci přiložit k zdrojovým kódům.

Není potřeba přikládat žádnou. Zdrojové kódy bez licence, jsou, jaksi, ehm, no BEZ LICENCE! , tedy implicitně nemá nikdo žádná práva, protože je autor neudělil. Licence není o tom někomu práva omezovat, ale UDĚLOVAT .

1549

Odkladiště / Re:Veřejné telefonní číslo

« kdy: 11. 06. 2018, 17:11:10 »

Když nevíš co znamená pojem veřejné číslo, tak příště neraď.

Velmi zajímavá reakce někoho, kdo se sám ptá.

1550

Odkladiště / Re:Nesvobodný open-source - jakou použít licenci?

« kdy: 11. 06. 2018, 14:53:41 »

"Nesvobodný open-source" považuji za oxymorón. Ovšem dala by se využít licence Freeware.

Zde jste střelil přesně opačně. Open source znamená, že zdorojový kód je otevřený přinejmenším k nahlédnutí. Open source samo o sobě neimplikuje možnost jej jakkoliv (svobodně) užívat.

Tedy: pokud chcete, můžete zveřejnit zdrojový kód k čemukoliv. Když nepřiložíte žádnou licenční smlouvu (ofertu), pak si kód může přečíst kdokoliv, ale tím to také začíná i končí. Pokud chcete něco UMOŽNIT, pak to napíšete do licence. Např.: tento zdrojový kód je povoleno analyzovat, překládat a užívat v testovacím režimu, za účelem ověření bezpečnosti. Jakékoliv jiné použití, ať už za úplatu, bezúplatně, nebo jako součást jiného produktu není povolena.

1551

Hardware / Re:Kde sehnat mini-power button?

« kdy: 10. 06. 2018, 16:22:06 »

https://www.gme.cz/tlacitkove-spinace-do-panelu

1552

Sítě / Re:Mikrotik, tunel na 2. vrstvě

« kdy: 10. 06. 2018, 15:39:45 »

Technologií, které Vám tohle umožní je víc. Ale nezapomeňte na takovou drobnost, jako že by tunelem měly procházet 1500b rámce. Nastavovat na všech zařízeních MTU menší než 1500 asi nebudete chtít. Pak Vám těch technologií moc nezůstane. Zafunguje určitě openvpn a pokud vím tak mikrotikový EoIP.

Problém s velikostí datagramu se dá docela dobře řešit, a dokonce je to někdy i žádoucí kvůli latenci. Neviděl bych problém snižovat MTU, v praxi se někdy hodí i extrémní snížení na 600 B. Pro jistotu je dobré na manglu přebít MSS na odpovídající hodnotu.

1553

Sítě / Re:Mikrotik, tunel na 2. vrstvě

« kdy: 10. 06. 2018, 11:19:18 »

A je ten požadavek na L2 opravdu oprávněný? Běží tam nějaká aplikace, která potřebuje komunikaci po L2? Rozšiřování broadcastové domény přes více lokalit je často cesta do problémů a tak se tomu snažím vyhnout.

Souhlasím, že je lepší se tomu vyhýbat a existuje jen opravdu zlomeček situací, kdy je to potřeba.

V takovém případě je v Mikrotiku Ether tunel. Když je nejhůř, (např. jeden konec je za NATEM, s dynamickou IP atd.), lze dokonce i navázat třeba OpenVPN a teprve v něm ether tunel. (Domyslete si, jaká bude režie a efektivita).

1554

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 09. 06. 2018, 17:49:59 »

Docela by mne zajimal Vas nazor, jak byste tuto situaci resil, pokud byste dostal zadani vyresit digitalni archiv danovych dokladu pouze elektronickou cestou v nejake smysluplne forme, bez el. podpisu (=prerazitkovavani). Nemyslim tim nejakou organizaci, ale soulad se zakony. Pro jednoduchost si predstavme firmu, ktera ma faktury prijate 1 ... 999999, k tomu soubory 1.pdf ... 999999.pdf (vse "originaly", nikoliv scany), nekdo to dokazal poridit bez chyb. Jake reseni byste zvolil?

Na to nelze bez kontextu odpovědět. V právu, včetně práva správního, platí principy přiměřenosti. Např. banky fungují na papíře a dnes i navíc skeny dokumentů. K tomu fyzicky má přístup k dokumentům jiná osoba, než ukteré lze předpokládat zájem je podvrhnout. Pokud máte dostatečně pevnou organizační strukturu a postupy ve firmě, měla by být neměnnost poměrně dobře prokazatelná. To je také důvod, proč "velkým projde víc".

Neměnnost souborů v čase můžete dělat přes ty sha sumy, jak navrhujete, plus protokolárně zaznamenat stav. Nikdo Vám dopředu neřekne, co v případě kontroly a třeba i soudů ustojíte. Bezpečné by mělo být kvalifikované podepisování a razítkování, ale to není zadarmo. V případě kontroly pak vůbec nemusí dojít na pochybnosti. Kontrola pochybnosti může rozptylovat různým způsobem. Např. křížovou kontrolou dokladů u druhých stran, nebo právě zkoumáním postupů ve firmě. V extrémním případě označí Váš stav za neprůkazný a vyzvou Vás, abyste dalšími prostředky prokázal. To je "oblíbená" praktika některých (podle mě ubohých) úředníků. Pak už Vám nezbude, než se rozhodnout, jestli sklapnete krovky, nebo jestli půjdete ke správnímu soudu. U správního soudu budete patrně prokazovat znalecky, jestli Váš způsob je v pořádku.

...běžná firma nechce tyto problémy riskovat, proto se chodí vyšlapanými cestami...

1555

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 09. 06. 2018, 09:30:46 »

Nevýhodou je a) situace, kdy PDF nemá elektronický podpis - tam nese zákazník riziko na DPH (prokazatelnost)

To bych neviděl jako riziko. Zákon o DPH nevyžaduje ani na papírovém daňovém dokladu podpis (ostatně, viděl jste někdy podpis na faktuře za telefon, elektřinu, ...).

b) situace, kdy sice podpis obsahuje, ale ten za rok či dva expiruje a bylo by vhodné řešit přerazítkování dokumentů (tuším co tři roky, dle doby platnosti).

Podle mě jste zamotal dvě věci do sebe. PDF faktura není elektronický doklad, to je listina zaslaná elktronickými prostředky. Podpis výstavce na ní není potřeba a není tedy ani potřeba přerazítkovávat.

Paradoxem je, že pokud najedete opravdu na elektronické faktury (strojovou výměnu informací), tak tam už zákon požaduje elektronický podpis a tedy i Vámi zmiňovanou povinnost přerazítkovávat. Podle mě je ten stav nesmyslný, cár papíru bez podpisu uznávat, ale elektronickou výměnu ne.

Druhým paradoxem je, že pokud příjemce chce listinnou fakturu uchovávat elektronicky (na straně příjemce), tak ji musí opatřit takovými záznamy, aby bylo jasné, kdo a kdy provedl konverzi do elektronické podoby, a že dokument nemohl změnit obsah. Takže pokud Vám přijde PDF faktura, tak ji můžete vytisknout a znovu skenovat, nebo si ji nechat v původní formě. Ale musíte doplnit kvalifikovaný podpis osoby, která dokument do elektronické archivace zařadila (a přerazítkovávat!). Tedy: listinný doklad může PŘÍJEMCE elektronicky, ale podpis musí doplnit on. Tím podpisem se neověřuje pravost dokumentu jako takového, ale jen to, že od určitého orazítkovaného data už nebylo s dokumentem manipulováno. Mně to přijde jako pěkná kokotina, raději ten samý dokument vytisknu a zařadím do šanonu, což státu stačí.

A opět by bylo nutné mít pořešen elektronický archív - tedy věc, které účetní nerozumí.

Absolutní souhlas. IT oddělení klidně archiv zavede, ale nebude to zadarmo. Ale ani IT ani účetní nejsou ta správná oddělení, která by měla provádět kontrolní činnost nad archivem dokumentů - jestli funguje správně, neztrácí data, dokumenty jsou průkazné a neměnné v čase, ... Takže ještě se musí zapojit management, aby tento proces zpracoval. Je to obdoba toho, že manažer čas od času projde účtárnou a vidí, jestli jsou lejstra v šanonech a skříních, jestli je místnost zamykaná atd. Do takových pakáren v elektronické podobě se firmám jednoduše nechce.

1556

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 08. 06. 2018, 18:08:25 »

Docela by mne zajimalo jak male firmy pouzivaji EDI(FACT) - jestli maji napojeni na VAN, nebo si jen vymenuji soubory?

Z mojí zkušenosti, malé firmy toto nevyužívají. Výjimkou jsou malé firmy dodávající pro velké korporace - tam je elektronická výměna motivována vyšším přiznaným rabatem. Ale to moc nepadá na váhu, protože taková malá firma používá EDI jen vůči řetězci a doklady pushuje k nim (obvykle přes obyčejneé FTP), ale vůči ostatním jede v listinách.

1557

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 07. 06. 2018, 22:43:32 »

Zkrátka je i tady vidět, že jste schopný akademicky fabulovat na libovolné téma, ale v těch oblastech, do kterých vidím já, si dlouhodobě a konzistentně udržujete zásadní rozpor s mými názory a zkušenostmi. Ale nejste v tom sám, je vás tady na fóru asi tak 5 takových. Škoda, že nejdete blokovat...

Napadáte mě zbytečně. Jak jsem psal, provozuji účetní firmu, pohovoruji a nabírám účetní. Účtujeme pro externí klienty. Někdy v našem systému, jindy v systémech zákazníka. V ČR (a v Evropě obdobně) máme výhodu, že existují jasné účetní standardy (Zákon o účetnictví, Český účetní standard), takže na práci jedné účetní může bez problémů navázat druhá. Jen musejí svému řemeslu rozumět a dělat podle standardu.

Pak existuje spousta "účetních", které to mají zaúčtované tak, že tomu zpětně rozumí jen ony samy - a to je ta sorta, o které si myslím, že hovoříte. Ty obvykle preferují jeden program, protože ho využívají jako suplement pro školení (na školení nechodí, ale v programu se jim najednou objeví něco nového a funguje to samo).

Je také možné, že si účetní zaměňujete s "nahazovačem" dokladů - tedy pracovníkem, který dokumenty typuje do počítače. Ale o tom já nehovořím. Odborná účetní málokdy nahazuje doklady (obvykle nahazuje složitější účetní případy, interní doklady apod.) - na běžné doklady, aby přepisovala, je příliš drahá. To dělají fakturanti, pomocníci - nazvěte to jakkoliv. V malých firmách nahazují faktury přímo kmenoví zaměstnanci - potřebují průběžně znát knihy závazků a pohledávek, zatímco účetní účtuje třeba jen 2x v měsíci.

Pokud jde o mě, za účetní považuji osobu, která ročně absolvuje přinejmenším 40 hodin školení a která ví, jak má být zaúčtováno, aniž by nutně potřebovala program, který ji vede. Té je pak jedno, jak se dostane k rozvaze nebo pohybům na konkrétním účtu, to už je jen detail který se liší v pár kliknutích.

1558

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 07. 06. 2018, 20:51:27 »

Obecně by všem více slušelo otevřít databázové rozhraní, aby ve vyšších verzích nebyla závislost na MS SQL, ale mohl to člověk provozovat i na jiném serveru než MS Win.

Zde bych nesouhlasil. Software, který bude mít tuto vlastnost, bude mít prakticky jistě řádkové zpracování a nedokáže SQL využít dobře (nelze mít zobecněné SQL a zároveň výkon a zároveň bezpečí dat). V tomto ohledu má problém i zmiňovaná Pohoda, která i ve SQL variantách pracuje řádkově (vznikla přepisem MDB verze do SQL, se všemi nevýhodami).

Závislost na MS Win serveru je nepodstatná, v režii firmy to hraje okrajovou roli. (Mimochodem MS SQL je i pro Linux).

1559

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 07. 06. 2018, 20:48:02 »

Pohoda má spoustu berliček pro začátečníky, které ale zkušenějšímu překáží. Například, abych opravil doklad, musím zrušit přiznání k dph, kontrolní hlášení, souhrnné hlášení, platební příkaz a vazbu na platbu v bance - často to smysl má, ale ne vždy. Pro začátečníka je to fajn věc, zabrání mu to udělat si bordel. Pokročilý si to musí všeliak obcházet.

Nemusíte. Dokonce byste ani neměl. Pokud zrušíte přiznání k DPH, tak nové kontrolní hlášení bude mít znovu status řádného, nikoliv následného. Ale je to poměrně rozšířená chyba u uživatelů Pohody.

Jistě, dobrý účetní dokáže pracovat i bez počítače... Ale pokud to dělá profesionálně, potřebuje být rychlý. Např. Money jsou imho uživatelsky rychlejší než Pohoda. Ale i Money poslední dobou upadají se mi zdá - po změně na Soliteu vidím posun k manažerským krasokecům. Uvidíme co bude dál.

Mám účetní firmu, práce v Pohodě, Money, Variu i Abře je jiná, ale výkon účetní je víceméně stejný. Jsou jiné postupy na kontrolu agend na konci měsíce - např. Pohoda nemá moc dobře vyřešené saldo, zase umí lépe zafiltrovat záznamy na kontrolu deníku, rozvahy a agendy. Neviděl bych v to, vítěze.

Pokud nějaká firma začíná, nechal bych výběr nástroje právě na účetní - pokud dosud nemá nějaký svůj oblíbený, svědčí to o nedostatku praxe a taková opička ještě nemá na to, aby pracovala samostatně.

Naopak. Znamená to totiž v lepším příadě ztrátu flexibility. Většinou to ale znamená, že taková účetní si nevystačí při kontrole práce s deníkem, rozvahou a saldem a spoléhá na nástroje uživatelských agend. Pokud nějaká účetní řekne, že vyžaduje konkrétní program, tak rychle utíkejte.

1560

Vývoj / Re:Jakou licenci pro můj SW použít, když chci zachovat původního autora

« kdy: 06. 06. 2018, 16:50:54 »

Případ busybox je myslím notoricky známý: https://arstechnica.com/information-technology/2010/08/court-rules-gpl-part-of-a-well-pleaded-case/

Já to neznal.