Příspěvky

766

Sítě / Re:Bezpečnostní úskalí RDP

« kdy: 22. 03. 2020, 09:56:46 »

Jde o to, co chcete chránit a před čím.

VPN do sítě přináší riziko rozšíření nějaké hrozby (viru) po souborech v síti.

Pokud jde o vzdálenou plochu, je bezpečnější variantou RDP přes RDP gateway (součást windows serveru) a bez VPN. Na RDP pak můžete zakázat připojení lokálních disků z PC uživatele.

Obecně bych víc preferoval RDP bez VPN, ale přes gateway. VPN pouze v případech, kdy uživatel potřebuje do celé sítě, ne jen na RDP. Alternativně můžete vytvořit VPN, do oddělené sítě, na které budou pouze RDP služby, ale ostatní služby sítě budou vypnuté. To je ale komplikovanější řešení, náchylné na chybu konfigurace.

767

Distribuce / Re:ZFS a Linux

« kdy: 22. 03. 2020, 02:09:21 »

(...) ve zdrojácích jádra je spousta souborů a dokonce i celých driverů, které mají duální licencování GPL2 např. s BSD nebo MIT - a když jejich autorům nevadilo, že je někdo může (vašimi slovy) "vykuchat a šířit bez zdrojových kódů", tak to prostě problém není. Koneckonců je to tak často právě proto, že tentýž kód je (případně s úpravami) používán i jinde. Ten skutečný problém, který se stále snažíte popírat, je, že CDDL takové duální licencování neumožňuje.

Podle mého vůbec není nutné vyžadovat duální licencování. Ta část kódu může zůstat čistě jen CDDL. Požadavek na pře-/podlicencování pod GPL je uměle, zbytečně vytvořený. Ono se to dá dovodit i selským rozumem: pokud mám já, jako uživatel (nebo maintainer distribuce) právo ty dvě části kódu (Linux pod GPL a ZFS pod CDDL) spojit v jeden funkční celek (a o tomto právu snad nikdo nepochybuje), na reálné situaci nic nezmění ani začlenění kódu do distribuce zdrojových kódů Linuxu. Jediné, co by bylo potřeba, by bylo administrativně oddělit původní ZFS dílo (které je pod CDDL) a kód od něj odvozený (neb ten by dál padal pod licenci CDDL), od vývoje jiných částí jádra tak, aby ty pod CDDL nespadly neúmyslně.

Do jisté míry chápu snahu Linuxu zachovat si čistotu a mít všechny části kódu pod GPL. Není však spravedlivé říkat, že za to může Oracle. Obě strany to mohou vyřešit naprosto stejnou měrou. A teď si řekněme, v čím zájmu by to bylo vyřešit? Oraclu je to u zadele, ZFS uvolnil a všichni ho mají k dispozici. Linux by ZFS zajímat mohlo, ale pánové se šprajcli. A veřejnost reaguje pudově: jakmile vidí článek, který má v perexu slovat Linux, ZFS, Oracle, licence, tak se jim zatmí, a aniž by si cokoliv přečetli, dovodí z toho, že Linuxu hrozí licenční spor s ošklivou komerční firmou. (Mimochodem, jaký soud ve které zemi by byl místně příslušný a kdo by byl žalovaným?)

768

Distribuce / Re:ZFS a Linux

« kdy: 21. 03. 2020, 22:03:20 »

Sun zveřejnil implementaci ZFS pod licencí, která je nekompatibilní s linuxovým jádrem a ani Oracle (který mezitím Sun koupil a má potřebná práva) ani v nejmenším nenaznačil, že by se chystal svůj postoj změnit.

milý Oracle, ať si ... Však víte co.

Mě by strašně moc zajímalo, kde se vzal ten dojem, že problém je s Oraclem. Licence CDDL umožňuje ještě volnější šíření než GPL, umožnuje ZFS začlenit do díla a dokonce nemusí být šířena se zdrojovým kódem. Ze strany Oracle žádný licenční spor nehrozí.

Co vadí maintainerům Linuxu je právě ta přílišná volnost. Linux je distribuován pod přísnější GPL (mj. podmínka šířit dál i zdrojové kódy, která v CDDL není) a pánům se zdá příliš nepohodlné mít části Linuxu pod různými licencemi.

Oracle už na této situaci nemá co dál vyjasňovat. Řekl: dělejte si ze ZFS cokoliv chcete a licenčně je to v pořádku.

Jestli někdo pro to může něco udělat, tak je to Linux. Připustit, že vybraná část jádra nebude GPL, ale ještě svobodnější CDDL. Podle mě by to ničemu neublížilo, jediný rozdíl by byl, že by ZFS mohl někdo další z Linuxu vykuchat a šířit bez zdrojových kódů, jen jako binární součást. V praxi by to neznamenalo žádnou změnu: ZFS tu je už nyní, a už nyní se dá dál šířit.

Ubuntu také nic neriskuje. Splňují jak GPL, tak CDDL. Oba produkty sloučili do jednoho díla (balíčku, distribuce). Linux je dál označený licencí GPL, ZFS je dál označeno CDDL.

Je pochopitelně na maintainerech Linuxu, aby se rozhodli, kam Linux směřují. Když ZFS do stromu jádra nevpustí, bude dál existovat nezávisle a najdou další, kteří to spojí a budou distribuovat. Právě tak, jak to dělá Ubuntu a jiní. Právě díky tomu, že neexistuje licenční překážka dál ZFS vyvíjet a Linuxem slučovat, rozhodně to není nějaká slepá ulička. Je to jen otravné a žabomyší spor.

769

Vývoj / Re:Hotové řešení sklad

« kdy: 20. 03. 2020, 19:57:52 »

To prave ne. Zbozi, ktere se vratilo, naskladnite zpet za skladovou cenu, za kterou jste ho vydal. To rozhodne nebude napr. pri ocenovani prumerem nakupni cena.

Máte pravdu, asi jsem to napsal nejasně. Správnou cenou jsem myslel takovou, která odpovídá předpisům, tedy ta, za kterou bylo vydáno. Pokud to bylo FIFO, odpovídá to přesně nákupní ceně, v případě VNC to odpovídá takové VNC, která byla v době výdeje. V tomto ohledu je FIFO podle mě jednodušší na operace s daty, než VNC.

770

Vývoj / Re:Hotové řešení sklad

« kdy: 20. 03. 2020, 19:08:05 »

...

Achich, hodně témat .

Interní směrnicí můžete upravit pravidla ve firmě, ale stále musejí zůstat splňovat Zákon o účetnictví a Český účetní standard (i ostatní předpisy). Zboží, pokud se Vám vrátilo (je Vaše), musí být k rozhodnému okamžiku naskladněno a za správnou cenu (nákupní cenu). Toto pravidlo obejít nelze, protože pak nesplníte požadavek na souvstažnost a potažmo s tím padá průkaznost účetní operace. Proto se to řešívá odděleným kolečkem kusových pohybů od účetních pohybů. Skladový systém eviduje kusy ve skladovém oběhu, ale chybí mu účetní pohyby. Na to se bohužel nedá rezignovat.

(S názorem, že zákon zle obejít interní směrnicí se setkávám, ale NELZE).

Přepočet VNC je důležitý, právě kvůli záporným stavům musíte používat funkci na přepočet a následně v údržbě databáze používat i přepočet cen. Pokud to děláte dobře, projde to bez problémů. V praxi se v Pohodě striktně zakazují pohyby do mínusu, právě kvůli obrovskému riziku rozpadu ocenění. Povolují se jen na chvíli při zvláštních operacích, které musí dělat opravdu znalá osoba. Zde moc doporučuji mínusové stavy úplně vypnout, je to cesta do pekel, věřte mi. Konkrétně Pohoda používá pro ukládání MDB nebo i MS SQL a provádí při údržbě spoustu operací. Přepočet VNC je jedna z nich.

Různé jednotky se řeší přes tabulku jednotek. Stanovují se pak převody do základní jednotky. Např. může být základní jednotkou gram (nějaké suroviny) a odvozenou jednotkou miligram, kilogram, balení či paleta. Skladové sestavy se pak tisknou v základní jednotce (je nemyslitelné sestavy ladit ručně na různé jednotky). Je potřeba si pohlídat rozlišení jednotek, aby nedocházelo k rozdílům.

Dotaz máte principiálně správně, musí se groupovat podle šarže (exspirace), jen nějak nechápu proč je to tabulka expirace-prijemky, z příjemek se to určitě brát nemá. Co byste na takovém dotazu chtěl zjednodušit?

Kód: [Vybrat]

SELECT
  id_zbozi,
  datum_exspirace,
  volne_kusy
FROM
  stav_skladu
  INNER JOIN exspirace -- může být podle situace LEFT JOIN
GROUP BY
  id_zbozi, datum_exspirace

771

Software / Re:RDP na Linuxu s Wine - bude to fungovat?

« kdy: 20. 03. 2020, 12:21:58 »

Alternativou k RDP je novy tenky klient, ale prepisat existujuce aPPky nebude praca na mesiac :-(

Zní to smysluplněji, než skládat technologie, které nemůžete ovlivnit, jak se budou chovat v budoucnosti. Budete si tím piplat vlastní produkt, to dává smysl.

772

Software / Re:RDP na Linuxu s Wine - bude to fungovat?

« kdy: 20. 03. 2020, 11:42:56 »

Hlavní problém vidím v té ceně.
Vlastní řešení znamená umět podporovat všechny technologie, které zvolím. Wine, Mono a další. To je trochu nepředvidatelné, může to fungovat roky dobře a taky to může vyžadovat neustálou péči. Tu za Vás nikdo neudělá (a když, tak rozhodně ne zadarmo). Místo vývoji a podpoře vlastní aplikace strávíte hodiny cenných lidí, aby dávali do kupy něco, co už je za pár šupů vyřešené od Microsoftu.

Jak už psali kolegové výše, kdyby to bylo řešitelné, už dávno by některý z gigantů postavil proti RDP konkurenci a vydělal by balík.

773

Vývoj / Re:Hotové řešení sklad

« kdy: 19. 03. 2020, 17:48:55 »

Hodnora skladu se počítá nákupních cen a množství zásob, což Pohoda bez problémů počítá i přepočítá zpětně. Já sám si počítám průměrnou nákupní cenu, kdy jediný rozdíl mi vzniká tím, že např. pokud já prodám poslední kus a ten den naskladním nové / nebo naskladním nové a prodám poslední kus, tak vznikají rozdíly mé a pohody, což, dle mého, jsou oba postupy v pořádku a hlavně rozdíly jsou naprosto zanedbatelné.

Vážené nákupní ceny jsou možná metoda, protože vedou stále k přesnému výsledku. Horší to ale je, když řešíte vratky (musíte znát nákupní cenu toho, co se vrací). Druhou chybou, kterou v Pohodě uděláte jsou reklamace a exspirované zboží. Pokud je nevyřídíte ze skladu okamžitě, rozjede se to už od reality. Pokud pan kolega napojuje externí systém, nelze očekávat, že účtárna tyto operace provede okamžitě.

Popisovaný problém s Pohodou se řeší v údržbě databáze, tam je operace přepočtu vážených nákupních cen.

774

Software / Re:RDP na linuxe+wine - bude to fungovat ?

« kdy: 19. 03. 2020, 16:09:11 »

Tak to můžete rovnou vzdát, nevím o nikom, komu by se to pro zákazníky povedlo.

775

Software / Re:RDP na linuxe+wine - bude to fungovat ?

« kdy: 19. 03. 2020, 15:28:45 »

Ano, pro přístup na MS server potřebujete User CAL + TS CAL, protože licenční model Microsoftu je buďto per user (co člověk z masa a kostí, to nutnost licence) nebo per device (každé jednotlivé zařízení). Alternativním softwarem na straně serveru se nevyhnete licencím.

Se zbytkem dotazu moc neporadím, protože jsem taky nenašel srovnatelně fungující alternativu k RDP. Spousta alternativ neumí ani H.264, takže fungují bídně.

Nevím pro kolik uživatelů to plánujete, nebo co Vás motivuje. Jestli je to jen úspora na CAL, tak s klidem mohu prohlásit, že jsem nepotkal firmu, která by dokázala pod 100 stanic nahradit RDP nějakým linuxovým řešením, aby se to finančně vyplatilo.

776

Vývoj / Re:Hotové řešení sklad

« kdy: 19. 03. 2020, 15:18:50 »

CO se týče účetních problémů, podklady pak importuju do účetního systému přes xml, výsledky stavu zásob jsou stejné, jenom vzniká rozdíl při postupu naskladňování.

Jak můžete importovat do účetního programu a jak může účetní program oceňovat sklad, když s oceněním nepracujete? Takto můžete maximálně importovat počet kusů, nic víc.

777

Vývoj / Re:Hotové řešení sklad

« kdy: 18. 03. 2020, 23:45:52 »

PS: v praxi jsem nejčastěji viděl, že firma si koupila nějaké jednoduché hotové řešení na Windows tak, aby data byla uložena v MS SQL. Do MS SQL pak lze jednoduše přistupovat i z Linuxu a nad daty si udělat např. výstupy. Pokud je potřeba provádět i vstupy, tak ty je nebezpečné zapisovat přímo do SQL (protože cizí strukturu dat nikdy neznáte dokonale). V takovém případě se vybírá i podle toho, aby daný systém měl nějaké API nebo třeba XML import dat pro opačný směr.

778

Vývoj / Re:Hotové řešení sklad

« kdy: 18. 03. 2020, 23:38:10 »

Souhlas s pány kolegy.
Nejprv musíte vědět, jestli firma účtuje sklady metodou A nebo metodou B.
Poté musíte vědět, jestli ocenění skladů je váženou nákupní cenou (= vážený průměr), nebo FIFO.
Pokud evidujete šarže nebo evidenční čísla kvůli exspiraci, nabízí se FIFO.
Při vratce do skladu se musí sklad zpět přecenit - a to musíte opět vědět, jakou cenou se ocení navracená položka.

Pak tu jsou i velmi praktické operace, které musíte v praxi řešit. Např. mít možnost expedovat zboží, které ještě nemá všechny náležitosti shromážděné. Přijede zásilka zboží (nebo zboží z vratky) a končí mu exspirace. Musíte ho rychle poslat dál. Máte k dispozici spediční doklady (dodací list), ale nemáte ještě účetní doklady (fakturu) kvůli ocenění. V takovém případě potřebujete umět dělat zbožní pohyby v nezávislém cyklu od účetních pohybů, ale zároveň neztratit o tom přehled.

Musíte umět evidovat reklamace (a další vyřazené zboží), protože ho máte zpět ve skladu (účetně máte i jeho hodnotu ve skladu, dokud nedojde k přecenění - to dělá účtárna na základě podkladů), ale zároveň není disponibilní. Nemůžete ho poslat dál. Přestože není v hlavním skladu, FIFO fronta nákupních cen se touto operací nesmí porušit, takže systém s nimi počítat musí.

Atomová věda to není, pracné to je. Každopádně potřebujete nejdřív znát, jak to funguje, poté se doptat na (nejen na tyto) důležité otázky. Dat a jejich zpracování je pak hromada a lze na tom využít sílu SQL. I v poměrně malém skladu už na těchto operacích zjistíte, jak moc práce budete mít s MySQL oproti tomu, kdybyste zvolil některou z "dospělých" databází. V praxi se z opensource nejčastěji volí PostgreSQL, z proprietárních pak MS SQL (neb lze začít na Express edition a pak poměrně "levně" přejít na Standard (levně v porovnání s Oracle)).

Když se do toho pustíte bez těchto znalostí, budete to přepisovat desetkrát od nuly, protože postupně zjistíte (řeknou Vám), na co všechno jste nepomyslel.

Zaujalo mě: aby to nabízelo zboží s nejkratší expirací. To mi přijde mimo skladovou realitu. Skladník nemůže hledat správné sériové číslo podle systému. Dělává se to tak, že skladníci musejí mít srovnané zboží podle exspirace a naopak jsou to oni, kteří dávají systému informaci o tom, jakou šarži / evidenční číslo vyskladnili. Je to mnohonásobně rychlejší, a funguje to docela dobře, pokud se ve skladu drží aspoň základní pořádek.

O hotovém otevřeném řešení nevím. Muselo by být české (kvůli českým účetním standardům), spíš pochybuji, že něco takového je volně k dispozici. Třeba můžete být první.

779

Distribuce / Re:ZFS a Linux

« kdy: 18. 03. 2020, 22:02:06 »

(přímo s blokovými volumes na ZFS mám fakt špatnou zkušenost, co se týká vytěžování CPU při větším vytížení I/O)

S Linuxem s tím zkušenost nemám, ale na FreeBSD jsem to řešil. Musí se ZFS naladit na konkrétní hardware (ve virtualizaci je to neřešitelné). Blokové volumes jsou dobré pro iSCSI targety, tam se ale většinou dedikuje hardware a opravdu se to nastavuje pro konkrétní situaci. Mix blokových a souborových svazků na jednom ZFS nedává smysl, právě kvůli výkonu.

Jinak s hodnocením ZFS s Vámi souhlasím, hlavně kvůli stabilitě. Btrfs takové stability nedosahuje a i jeho vývoj ukazuje, že spíš míří do SOHO segmentu (není moc aktivních přispěvatelů, ani testerů pro enterprise features).

Pokud mě něco trápí na ZFS, tak je to rozežranost deduplikace a nemožnost deduplikovat offline. To bych velmi ocenil - a na tyto případy používám raději - světe div se - NTFS, které to umí výborně.

780

Vývoj / Re:Bezpečná session v PHP

« kdy: 18. 03. 2020, 15:45:15 »

Nařízení si nepřečtete, názor ÚOOÚ si nepřečtete, ale dál trváte na tom, že jedině vaše dojmy jsou správné.

Četl jsem vše zmiňované, včetně uznávané právní literatury k tématu.

Vzhledem k tomu, že všude potkávám nejrůznější nesmyslné cookie lišty, které nevyhovují ani GDPR, ani obchodním podmínkám Googlu, ani ničemu jinému, evidentně to nařízení tak jasné není.

Zájem uživatelů určitě není na každém druhém webu skrývat při každé návštěvě nějakou nesmyslnou lištu, jejíž zobrazení či nezobrazení nemá žádný vliv na funkčnost webu. Pokud nějaký uživatel má potřebu nějak řešit cookies, ať to řeší ve svém prohlížeči, To je jediné místo, kde se to vyřešit dá.

Ano, s tím souhlasím, že se většina firem snaží nařízení obejít, občůrat opt-out lištami, které neplní účel. Není však důležité, že se masy rozhodly na nařízení prdět, ale to, jestli to lze splnit či nikoliv. Já jsem přesvědčený, že lze, jen to bude vyžadovat změny. Tedy dokud není funkce cookie nezbytná, nesmí ji web nastavit. Pokud je nezbytná, smí. A smí ve chvíli, kdy o to člověk požádá opt-in způsobem (např. souhlasem při zakládání účtu a následně loginem).

Celá naše diskuse se točí kolem toho, že se Vám zdá směrnice nepohodlná a že vyžaduje změnu systémů i přemýšlení při plánování. Až bude chtít zákonodárce, aby si to uživatel ovládal v prohlížeči, vypustí to z normy. Do té doby to tam je.