Příspěvky

361

Server / Re:SFTP, ChrootDirectory, a přístup uživatelů do VirtualHost (každý odděleně)

« kdy: 14. 01. 2022, 09:39:08 »

Každá doména bude mít vlastní chroot (dále příklady pro první doménu) /var/www/domena1_cz/, který vlastní root:root 775 (včetně všech rodičů).
Virtuální adresáře Apache pak odkazují na složky /var/www/domena1_cz/www/. Tuto složku vlastní www-data:www-data 775.

Jak dlouho chcete cekat, nez ten server nekdo hackne? Tohle neni multiuzivatelsky bezpecne ani na prvni pohled.

jj, tohle je skvělé, každá aplikace může číst soubory té druhé, stačí znát doménu/cestu, to znamená, že si může přečíst vše vč. hesel do databáze a potají jen doufám, že php server neběží také pod uživatelem www-data, to by si mohli i navzájem zapisovat . Takhle přesně to měl před 15 lety banán, než ho hackli a Radovan se ještě kasal, jací bezpečnostní experti mu s tím pomáhali.

Tohle opravdu není dobrý nápad.

Správné řešení je mít uživatele pro každý účet, nevázej to na doménu, stejně tak název domény by se neměl objevit v názvu účtu, protože např. délka domény může být delší než je povolena délka uživatelského jména na linuxu a jiné špeky, je tedy vhodné název účtu generovat. PHP proces by měl být uzavřený v chrootu, neměl by vidět nic víc než svoji složku, veřejně viditelné věci jako /etc/passwd, /etc/hosts a jiné bys měl generovat pro něj extra, aby neviděl tvoji infrastrukturu nebo jiné uživatele. Uživatelsky přívětivější verze chrootu je docker či containery obecně.

362

Server / Re:Co už je v MariaDB veliká tabulka?

« kdy: 14. 01. 2022, 09:00:52 »

Ono sa lisia viac menej v nazve.

kdy naposledy jsi ty databáze viděl? Po několika letech práce Oraclu na MySQL 8 bych mu neříkal, že se to pořád liší jen v názvu. Rozdílů je tam už více než dost, nemluvě o tom, že se nám rozrostl počet dostupný enginů.

Všiml jsis, že tady máme InnoDB, které umí indexy a nikoliv jen MyISAM?

363

Server / Re:Co už je v MariaDB veliká tabulka?

« kdy: 13. 01. 2022, 17:01:45 »

Okolo 10 000 zaznamov je pre MySQL velka tabulka.

naštěstí tady je řeč o MariaDB.

364

Vývoj / Re:Normalizace databáze

« kdy: 13. 01. 2022, 12:04:03 »

1NF - atribut nesmí být dále dělitelný, součet hodnot je dělitelný na jednotlivé podsoučty
3NF - atribut musí být závislý pouze na primárním klíči, vypočítané hodnoty v balance tabulce jsou závislé na datech v transakcích, nikoliv pouze na svém primárním klíči

když už se bavíš o normálních formách, tak tabulka balance by měla mít primary key (account_id, datetime), unique je pak implicitní, aby se dodržela 2NF.

Balance u účtů můžeš uchovávat, pokud takový údaj ale pochází z venku a nikoliv ze samotných transakcí, tj. záleží jaká je vlastně vazba mezi hodnotami. V bankovních systémech se extra počítá účetní stav k nějakému dni, ten je dán aplikační logiku a nepřímo pochází z transakcí (ovlivňuje ho ale třeba i zaokrouhlování, tj. nikoliv jen transakce), ten stav je pak materializován v databázi a denní změny jsou k němu připočítávány za provozu. Tím se samotná normalizace neporušuje.

Je pak otázka jestli takové cachování v balance tabulce není předčasná optimalizace.

365

Vývoj / Re:Frekvenční analýza výskytu řetězce?

« kdy: 13. 01. 2022, 08:42:46 »

mate k dispozici vice stroju, ze by slo praci rozsekat ukol na n samostatnych pocitacu.

Jak se tohle paralelizuje? Podle mě bude bottleneck velikost paměti, protože těch možných stringů je… hodně (64**10, resp. 10*velikost_vstupních_dat). Pokud jsou statisticky hodně nerovnoměrně rozdělené (což v „lidském textu“ jsou), tak by to možná šlo nejdřív předfiltrovat třeba počítáním 32bit hashů těch substringů (nějaké zkolidují) a v druhé fázi počítat jenom ty co se zahashovaly do bucketů kde toho je nejvíc.

ano, přesně takhle se to paralelizuje, spočítaj se postupně kolidující stringy (buď využití hashe nebo v případě stejné délky řětězců jdeš postupně po písmenech) a přiděluješ jednotlivé prefixy nějakému výpočetnímu procesu. Frekvenční analýza je aditivní výpočet, lze tedy počítat postupně a připočítávat mezivýsledky, dobře se to paralelizuje.

366

Server / Re:co uz je velika tabulka (MariaDB)

« kdy: 12. 01. 2022, 15:15:29 »

To je ještě malá tabulka , v absolutních číslech, už dnes se potkáváme s tabulkami o 10TB velikostech. Ona to velikost je ale nepodstatná, i u titěrné tabulky mohou mí problémy s výkonem, záleží jak jí používám.

Při takovémhle počtu záznamů bude velký problém jakákoliv změna struktury tabulky, doporučuji se podívat na pt-online-schema-change od Percony. Generování nových indexů je porovat, vhodnější je pouze indexy měnit. Pokud má vysoké přírustky, tak mergování B-tree stromů pro indexy začíná být nejdražší operace vůbec, vyplatí se záznamy vkládat pohromadě. Samozřejmě partitioning je tvůj kamarád, vždy je lepší tabulky vertikálně nebo horizontálně rozdělit na více jednotek. Ty právé problémy totiž nastávají při obnově nebo vytvoření nové replikace.

367

Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu

« kdy: 06. 01. 2022, 23:58:12 »

Tak ide to aj bez zbytocnych cyklov alebo callbacku pre kazdy vyskyt. To je v podstate skryte GOTO label. Regexpy vedia aj OR.

Kód: [Vybrat]

const
handles = ["john", "johnathan", "sarah"],
topics = ["home", "hometown"],
tmpString = "@john and @Johnathan went to see @sarah in their #hometown to look at her new #home.";

function rplacer(text){
  return tmpString.replace(
    new RegExp('@('+handles.join('|')+')\\b','gmi'),`<a href="/user/$1"@>$1</a>`
  ).replace(
  	new RegExp('#('+topics.join('|')+')\\b','gmi'),`<a href="/topics/$1">#$1</a>`
  );
}

console.log(rplacer(tmpString))

Takhle můžeš jen doufat, že nikoho nenapadne zadat handles = ["john.doe"], ono to jde ještě dál, hodnoty v handles a topics se dají přímo využít pro XSS. Takovýhle způsob psaní kódu je dost nebezpečný.

368

Software / Re:Jak monitorujete tok dokumentů?

« kdy: 06. 01. 2022, 13:54:41 »

Je to dost vágní otázka, ale asi by to chtělo zabalit ty dokumenty do zpráv, které mají i nějaká metadata: unikatní id, verzi a stav a payloadem bude vlastní dokument. Posílat ty zprávy přes nějakej messaging a monitoring se příhlásí k odběru na jednotlivých translacích. Pak už se dá snadno dohledat, že systém A publikoval zprávu 1, ale systém B, který ji měl zkonzumovat, transformovat a poslat dál už to neudělal. 
Děláme tohle v bance, ale máme vlastní řešení.

osvědčilo se mi naopak dokumenty nebalit do samotné zpráv (oni některé mohou být opravdu dost velké a víme jaké mají messaging systémy omezení na velikost), ale opatřit elektronickým podpisem/časovým razítkem, které daná metadata nese, je to poté i poměrně transparentní pro uživatele, protože v rámci samotného dokumentu již vše potřebné vidí.

Pokud není možné připojovat podpis do dokumentu (ne všechny formáty to umožňují), stačí jen držet hash a jméno daného dokumentu a ten mít poté uložení v jakémkoliv uložišti. Při jeho zveřejňování je ale nutné vždy ověřit jeho stav a podle toho se zařídit, to zase ne všechny systémy dobře umí.

Banky běžně dokumenty jako jsou smlouvy, výpisy, scoring informace drží jako bloby (často šifrované) a dále pracují pouze s hashem daného dokumentu, ten i prochází různými workflow, přenášet přes roury samotný dokument moc často nevídám, ale víme jak ty systémy jsou diverzifikované, takže asi i tahle varianta někoho napadla.

369

Software / Re:Jak monitorujete tok dokumentů?

« kdy: 06. 01. 2022, 09:05:48 »

v tom případě ale musíš počítat s podporou/integrací SW, který teď používáš na zpracování dokumentů, to nelze udělat bez toho. Pokud chceš poradit, musíš tady popsat svoji infrastrukturu a tok dokumentů, podle toho se musí vybrat vhodný nástroj, vhodná integrace a postavit nad tím dohledové workflow.

TB dat nejsou problém, vše záleží jaké vlastní střednědobé náklady očekáváš a kolik do toho chceš investovat. Lze jít cestou vlastního vývoje, dokoupením modulů (na SAP je možné navázat ledacos) nebo pořízením nezávislých aplikací, které budou čerpat data vedlejšími kanály (z logů, api, přímo z databází, ze samotných souborů atd.).

Zkušenosti mám z bankovního sektoru, tam se ale vše řeší kanónem za neskutečné peníze.

370

Studium a uplatnění / Re:Profinit - junior java dev

« kdy: 05. 01. 2022, 19:32:26 »

Dva roky jsou možná ještě na hraně, ale pro lidi se třemi lety praxe je podle mých osobních zkušeností z loňského roku 5000k/MD skutečně běžná suma pro průměrně inteligentního člověka bez technické VŠ. Zkoušel jsem asi patnáct pozic a většina se pohybovala v rozmezí 4500 až 6000. A ano, mluvím o firmách působících v ČR (T-Mobile, Komerční banka, PwC, IBM) a ne full remote do Sillicon Valley.

Zrovna s třemi ze čtyř tebou vyjmenovaných společností spolupracuji a nedávají 90+ hrubého na smlouvu lidem s 3 roky praxe, na kterou pozici a do jakého oddělení jsi tam šel? Tohle dostávají pouze kontraktoři přes třetí strany.

Zodpovědnost? Programovat je úžasné v tom, že žádnou zodpovědnost člověk vlastně nemá, když každá změna projde code review, atd... Je to v podstatě nevymahatelné, takže jsem v klidu.

Důchod? Podle mě je lepší mít na důchod např. 4 nemovitosti, které může člověk pronajímat nebo časem prodat, než se spoléhat na náš důchodový systém a dostat pár tisíc za to, že ho stát obíral na socce celý život.

Myslím, že tě realita může velice rychle překvapit, právní odpovědnost samozřejmě máš a společnost to po tobě může vymáhat.

Stejně tak mysli na to, že práce na ŽL pouze pro zahraničního partnera není zrovna v souladu se naším zákonem. Nemovitosti ti za 30, 40 let budou generovat další náklady na jejich údržbu. S pracovní smlouvou dostaneš hypotéku, která je mimochodem vzhledem k inflaci pořád lepší než si na nemovitost spořit a jako bonus nepracuješ v šedé ekonomice. Dělám celý život legálně a kupodivu jsem si také mohl koupit nemovitost...

371

Studium a uplatnění / Re:Profinit - junior java dev

« kdy: 05. 01. 2022, 16:42:08 »

Nemá cenu dělat v české firmě, když všechno je remote. Angličtinu se naučíš i za 2000 hodin nějakých seriálů při studiu a nic víc člověk nepotřebuje.

Já bych vzal shit pozici jen kvůli praxi, kdybych nedokázal najít nic jiného, a to max. tak na rok a pryč.

a co třeba důchod? Pojištění? Nemocenské? Nebo třeba jen taková banalita jako, odpovědnost za chyby, nechrání tě české zákony, mohou po tobě vymáhat neomezené částky.

Ne nesmysl ve vlákně o profinitu tady doporučovat zahraniční kontrakty.

372

Software / Re:Jak monitorujete tok dokumentů?

« kdy: 05. 01. 2022, 16:39:11 »

v enterprise světě se tohle dělá v BPM (Business process management), často tyhle SW mají vystřčené api, přes které změny uvozuješ.

Tohle si ale můžeš implementovat na koleni, tabulka v databázi, api nebo webové rozhraní pro práci s tím a zanášení změn. Pokud to ale potřebuješ implementovat do tvého existujícího procesu nebo SW, to bude obtížnější.

Stejně tak se na to dá poměrně dobře použít SW pro ticket, např. Jira, TargetProcess aj., sice k tomu nejsou určeny, ale často takovéhle věci jsou už ve firmách, tak proč použití nerozšířit.

Mrkni třeba na https://github.com/kiegroup/jbpm, https://camunda.com, https://www.joget.org, případně řekni co se ti na tom nezdá a pokusím se vymyslet jiné alternativy.

373

Vývoj / Re:Hledání a nahrazování pomocí JavaScriptu

« kdy: 05. 01. 2022, 15:38:20 »

SO odpoved ak by niekto potreboval do buducna:

Kód: [Vybrat]

var tmpString = `@john and @johnathan went to see @sarah in their #hometown to look at her new #home.`,
handles = ["john", "johnathan", "sarah"],
topics = ["home", "hometown"];
console.log(tmpString);

for(var i = 0; i < handles.length; i++) tmpString = tmpString.replace(new RegExp(`(@${handles[i]})+(?![A-Za-z0-9])`, 'gmi'), `<a href="/user/${handles[i]}">@${handles[i]}</a>`);
console.log(tmpString);
for(var i = 0; i < topics.length; i++) tmpString = tmpString.replace(new RegExp(`(#${topics[i]})+(?![A-Za-z0-9])`, 'gmi'), `<a href="/topics/${topics[i]}">#${topics[i]}</a>`);
console.log(tmpString);

lze to udělat i takhle:

Kód: [Vybrat]

const regex_topics = /#([a-zA-Z0-9_]+)/ig
const regex_handles= /@([a-zA-Z0-9_]+)/ig
let text = "@john and @johnathan went to see @sarah in their #hometown to look at her new #home."

const handles = ["john", "johnathan", "sarah"]
const topics = ["home", "hometown"]

function createAnchor(url, text) {
  let c = document.createTextNode(text);
  let a = document.createElement('a');
  a.setAttribute("href", url);
  a.appendChild(c);
  return a.outerHTML;
}

text = text.replace(regex_topics, function(value) {
  let i = topics.indexOf(value.substring(1).toLowerCase())
  if (i>-1) {
    return createAnchor("/topic/"+topics[i], value)
  } else {
    return value
  }
});

text = text.replace(regex_handles, function(value) {
  let i = handles.indexOf(value.substring(1).toLowerCase())
  if (i>-1) {
    return createAnchor("/user/"+handles[i], value)
  } else {
    return value
  }
});

Vyhneš vyhledávání přes regulární výraz ve smyčce, drahýmu dopřednými hledání, stejně tak mám ošetřené escapování a vstupní hodnoty, do url dosazuji vždy variantu s malými znaky (v tvém řešení se ti budou velká písmena přepisovat i do url).

374

Hardware / Re:Flash disk se zabezpečením

« kdy: 05. 01. 2022, 12:14:52 »

Asi nejlepší je dnes VeraCrypt kontejner na flashce.
Z HW řešení bych doporučil 2,5" USB3 box Zalman VE400,který má hardwarové AES a po 10 chybných pokusech disk skartuje,ale už se nevyrábí,protože Zalman byl odkoupen konkurencí a zrušen.

Zrovna ten ZAlman VE400 je průser, má sice AES, ale nemá bezpečně uchované klíče, nemá vyřešený bezpečný generátor soli, i bez pinu odpovídá na AT příkazy a je možné přes upravený kabel samotný pin získat, dokonce i resetovat ho do továrního nastavení.

Stejně jako ty zmíněné v otázce, na zabezpečení proti náhodným kolemdoucím to je super, ale pokud to má být pro bezpečné uložení informací, rozhodně to není dobrý nápad.

A jak to poznat v praxi? Výrobci, kteří se nespecializují dlouhodobě na bezpečnost, ale jedná se o konzumní producenty příslušenství vesměs zatím nikdy nevyprodukovali bezpečné zařízení. HW, který odolá řadě různých útoků a k tomu ověřený SW je pekelně drahá věc, takové zařízení nebude stát stovky, ale tisíce. V popisu takových produktů je dobré hledat klíčové slovo HSM, ověřit si certifikace a audity, aspoň, že jich to řadu má a že tomu důvěřují společnosti v oboru.

Z těch dostupný je třeba zajímavé zařízení f-secure USB armory, ale pořizovací cena jde to tisíců.

375

Studium a uplatnění / Re:Profinit - junior java dev

« kdy: 05. 01. 2022, 11:57:22 »

Jinak si myslím, že po dvou letech je 5000/MD nebo minimálně 60k hrubého naprosto reálná mzda, ale záleží na spoustě faktorů. Na druhou stranu zrovna v profinitu to fakt asi nedají... Zjednodušeně, kdo si o to řekne, možná to nedostane, ale kdo si o to neřekne to určitě nedostane.

Dělám v oboru 40 let a platy, které se tady na rootu označují jako "běžné", "reálné", "dosažitelné" mi připadají jak z říše snů. Po 2 letech v praxe opravdu není běžné mít takové peníze, možné to je, ale pravidlem bych to neoznačil.

Nevím odkud se bere to očekávání, chodí mi na pohovor spousty lidí, kteří mají praxi v měsících, jednotek let, tváří se jako zkušení a říkají si právě o takovéhle peníze. Už dlouho jsem na pohovoru nepotkal člověka po škole, který by měl hlubší znalosti aspoň v něčem a vyšší mzdu by si zasloužil.

Dělám odborné pohovory u tří velkých společností a prochází mi rukama spousty CV už dlouhodobě, samozřejmě nemám přehled o celém trhu, ale nevěřím, že existuje ostrůvek, kde běžně dávají 5k/MD po 2 letech.