Příspěvky

2581

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 19. 04. 2019, 12:58:53 »

K tomuhle testu se vztahuje vysledek ve smyslu celkhoveho zatizeni pocitace u Postrges vs javovsky Hibernate.

Který je ovšem závislý na způsobu použití PostgreSQL, na způsobu použití Hibernate, a na způsobu použití dané aplikace. Jenom v tomhle jednoduchém příkladu tedy máte tři nezávislé proměnné, takže jeden test vám neřekne vůbec nic.

Navíc vy přece ani nechcete nic testovat, vy už máte o výsledku jasno.

2582

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 19. 04. 2019, 12:37:00 »

tam se toho da vyzkouset tolik.

Já jsem se ale ptal, k čemu to bude.

Napr. rozjet Postgresql lokalne a pouzit Hibernate pro praci s entitami, bez pouziti second level cache. Pak zkusit nasimulovat delay do te databaze a zapnout second level cache a porovnat vysledek. Potom zkusit zapnout diskPersitence u te cache a porovnat vysledek. Ucelem toho mereni je, porovnat performance cache kterou ma Hibernate v Jave a kterou by melo Postrgesql. A ty prerformance testy udelat poradne, simulovat treba 100 paralelnich requestu za vterinu.

Ano, to se dá udělat. A zjistí výsledky, které se vztahují přesně k tomuhle jednomu testu, které ale budou k ničemu ve všech ostatních případech, např. u reálných aplikací. K čemu to tedy bude?

Ucelem toho vseho je doakazat, ze Hibernate a Java je sracka co akorat zere RAM a zatezuje servery A nebo mozna prekvapi? 

Aha, tak to vysvětluje vše. Prostě máte nějaký výsledek, a teď sháníte libovolný postup, jak se k němu dostat.

Da se otestovat spousta zajimavych veci a kdyz se to udela poradne, tak z toho bude uzitecny vystup.

Aby z toho byl užitečný výstup, musel by otestovat tisíce různých kombinací aplikací, databází, způsobů zátěže a konfigurací. Ten váš příklad s cache nevypovídá vůbec o ničem, protože účinnost cache se samozřejmě bude dramaticky lišit v závislosti na formě pracovní zátěže – záleží na poměru mezi čtením a zápisem, na tom, zda se čtou opakovaně stejná data, na tom, zda je povolené poskytovat starší data.

Kdezto kdyz bude nekdo vyrabet jakousik webovku, tak to stejne bude stat za houby a nebude to k nicemu, akorat to skonci na skladisti bakalarek tak jako u miliony jeho predchudcu.

Webovou aplikaci je možné jako bakalářskou práci udělat pořádně. Vaše měření v žádném případě. Myslíte, že mu někdo pro účely bakalářské práce půjčí Exadatu, stovky gigabajtů dat a stovky uživatelů, kteří budou provádět reálnou práci? Když jste to chtěl vztahovat na enterprise informační systémy…

2583

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 19. 04. 2019, 09:48:26 »

Jak ze na tom nic nevyzkoumas, to si delas srandu ne. Zrovna ohledne cachovani o kterem pises muzes porovnat perfromance SQL a Hibernate kdyz ma databaze delays ze je jakoze remote a kdyz je databaze na stejnem stroji. Databaze si taky umi cachovat, takze nepotrebujes mit cache 2x, paklize jede ta DB na stejne masine.

Co na tom vyzkoumáte jiného, než síťový round-trip databáze?

Uz i samotne na tom nic nevyzkoumas je hlod, vsude se delaji enterprise informacni systemy a tomuhle malokdo dobre rozumi.

Co na tom tedy vyzkoumá užitečného? Tedy takového, co bude platit i pro jiné případy, než pro ten jeden, který zkoumal? V reálném světě je každý systém jiný a chová se jinak. Chování se mění i v závislosti na tom, kolik je zrovna aktivních uživatelů a co dělají. A zrovna u enterprise informačních systémů se milisekundy zpoždění síťové odezvy při přístupu do databáze opravdu neřeší. Navíc u enterprise systému by snad nikoho nenapadlo provozovat aplikační server a databázi na tom samém stroji.

2584

Server / Re:SFTP vs FTP bezpečnost

« kdy: 18. 04. 2019, 22:22:24 »

A co si tak treba o fail2ban alespon precist manualovou stranku?

fail2ban  -  a  set  of server and client programs to limit brute force authentication attempts.

Vy jste nepoučitelný. Přečetl jste si to, co jste zkopíroval? Umíte si přeložit, že „authentication attempts“ znamená např. „pokusy o autentizaci“? V jakém světě „bušení na porty“ v kontextu síťové komunikace znamená „pokusy o autentizaci“?

Pro vaši informaci, fail2ban obvykle zmaří opakované pokusy o navázání spojení, protože po několika neúspěšných pokusech na firewallu na daném zařízení zablokuje příslušnou zdrojovou IP adresu (což je výborné ve světě zamořeném NATy). Nezabrání ale tomu, aby paket zahajující spojení přišel. To by musel komunikaci zablokovat někde dřív, třeba na síťovém firewallu. Pak by útočník „nebušil na porty“ cílového serveru, ale jenom na síťový firewall.

fail2ban může ještě fungovat tak, že když se útočníkovi nepodaří vůbec navázat TCP/IP spojení, nebude to s dalším heslem už ani zkoušet. Což ovšem vyžaduje určitou inteligenci od útočníka, a inteligentní útočník nejspíš nebude ani zkoušet různá hesla, když server autentizaci heslem vůbec nepodporuje.

Každopádně fail2ban není bezpečnostní opatření, protože když bude mít útočník motivaci, může ta hesla zkoušet z různých IP adres, a fail2ban si pak ani neškrtne.

2585

Server / Re:SFTP vs FTP bezpečnost

« kdy: 18. 04. 2019, 21:50:03 »

Pokud neches, aby ti trvale nekdo busil na porty SSH a FTP, tak se vyplati nasadit i fail2ban

…který ovšem „bušení na porty“ (tedy pokusům o navázání spojení) nijak nezabrání.

2586

Server / Re:SFTP vs FTP bezpečnost

« kdy: 18. 04. 2019, 21:00:38 »

Moje otázka je, zda je opravdu bezpečné vystavit SSH port 22 do internetu a co by se mělo pohlídat aby nevznikl nějaký bezpečnostní problém?

Nedávno se to tu dlouze řešilo.

Je to bezpečné, pokud zajistíte:

• Aktualizovaný software, který to ovlivňuje (jádro, SSH server a knihovny, které server používá).
• Používat bezpečné, tj. především aktuální, protokoly a algoritmy.
• Povolit přihlášení pouze klíčem (čímž se zbavíte problémů se slabými hesly).
• Držet klíč v tajnosti, používat rozumně dlouhý klíč.

2587

Server / Re:NTP Servery, timezone

« kdy: 16. 04. 2019, 14:10:04 »

Otázka je, čemu říkáte časové pásmo. ČR je pořád v časovém pásmu Europe/Prague. Tohle časové pásmo se ale 7 měsíců mapuje na středoevropský letní čas (SELČ), což je UTC+2, a zbývajících 5 měsíců se mapuje na středoevropský čas (SEČ), což je UTC+1. Nebo-li časové pásmo Europe/Prague se nemění, ale časová pásma SEČ a SELČ se střídají.

Pokud máte v konfiguraci nastavené časové pásmo Europe/Prague, mělo by to fungovat a to „přepínání“ se dělá automaticky (ve skutečnosti je to jen volba správného přepočtu). Pokud byste měl nastavené časové pásmo SEČ nebo SELČ, nebo měl nastavený jen ofset od UTC, tak to přepínání samozřejmě nemůže fungovat.

2588

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 15. 04. 2019, 21:46:43 »

děkuji za pěknou inspiraci. Mohl byste, prosím, rozvinout tu druhou část? Mohl byste mi vysvětlit, jak si představujete tu část s RESTEM? A to s multitenant - "aby se to na jednom serveru dalo provozovat pro víc spolků" - to znamená, že bude jeden server, jedna databáze, do které se budou ukládat všechny ty spolky, informace a další data...
Tedy prakticky: Byl by napsán server ve springu s REST, a potencionální uživatelé by používali tu klientskou část, která by přes AJAX stahovala data ze serveru, že? S tím, že několik spolků může být spravováno v jeden čas.
Díky

Psal jste, že byste použil REST s AJAXem. To zapadá do mé představy, jakou by taková aplikace měla mít architekturu – na backendu Spring, který bude veškeré služby poskytovat přes RESTové API, a jako frontend klasická SPA, která bude volat to RESTové API. Mně by se pro tu frontend část nejvíce líbilo Vue, ale klidně to může být třeba Angular nebo React.

Má poznámka k RESTu pak směřovala k tomu, aby to RESTové API bylo navržené tak, že může fungovat i samostatně, bez té webové aplikace. Často se totiž stává, že když se navrhuje RESTOvé API pro jednu konkrétní SPA, je to API s tou frontendovou aplikací natolik svázané, že prakticky nejde jinde použít. Tady by ale myslím bylo vhodné, aby cokoli, co půjde udělat přes webový frontend, šlo (bez větší námahy) udělat i voláním API. Například klasický postup přidání nového člena spolku by byl takový, že to nějaký administrátor spolku nakliká přes webové rozhraní. Ale spolek už má třeba jinou evidenci a chtěl by používat jiné funkce té aplikace – tak si udělá propojku, která přes to RESTové API bude vytvářet členy na základě toho druhého systému.

Multitenant znamená, že se aplikace provozuje jenom jednou (typicky jen s jednou databází), ale z hlediska uživatelů se to chová, jako kdyby to bylo víc nezávislých aplikací, pro každý spolek jiná. Např. můžete mít jednu instalaci účetního programu, vede se v ní ale účetnictví několika firem. Z pohledu uživatelů se to chová, jako by účetnictví každé firmy bylo zvlášť – nesmí se tedy stát, že by účetní jedné firmy viděl nějaké údaje z jiné firmy, nebo že by si i navzájem mohli jenom měnit konfiguraci.

Nejsnazší by samozřejmě bylo mít pro každou firmu/spolek jinou databázi, jenže to je zejména ve webovém prostředí obtížně řešitelné – pokud byste měl na jednom serveru třeba 100 databází, těžko může server udržovat třeba 400 spojení do databáze (pro každou databázi 4), která by byla většinu času neaktivní. Druhá možnost je mít vše ve společných tabulkách, prakticky v každé tabulce pak tedy musí být i sloupec určující, do které firmy daný záznam patří. Pak je samozřejmě potřeba ve všech dotazech přidávat i podmínku na aktuální firmu, aby se právě nestalo, že se někde zobrazí i údaje někoho jiného. To je jedna nevýhoda, druhá nevýhoda je, že se pak jednotlivé firmy ovlivňují více, než je zdrávo – když budete mít devět firem, každá bude mít deset faktur, a desátá firma bude mít deset tisíc faktur, penalizované za to, že pracují s tabulkou o desetitisíci záznamech (což je tedy pořád málo, ale v jiných tabulkách může být těch záznamů řádově víc), budou všechny firmy. Většina relačních databází pak umožňuje ještě něco mezi, že se připojujete k jedné databázi, ale uvnitř ní je víc prostorů, které jsou do jisté míry oddělené. Třeba v PostgreSQL by se pro tohle dala použít schémata.

Ale zároveň to není věc, která by tam musela být za každou cenu hned od začátku, asi to není věc, která by se řešila na úrovni bakalářské práce. Ale dá se s tím počítat třeba na úrovni API – třeba účetnictví Flexibee to má dělané tak, že první položka cesty v URL je vždy identifikátor firmy. Takže třeba pro seznam faktur Firmy1 voláte https://www.example.com/firma1/faktury a pro seznam faktur Firmy dva voláte https://www.example.com/firma2/faktury. Mimochodem zrovna Flexibee má docela pěkné API, ve kterém jde udělat skoro všechno, co umí ta aplikace samotná.

Pokud byste měl nějaké další dotazy, klidně se ptejte. Já budu rád, když taková aplikace konečně vznikne a nebudu jí muset příště psát znova sám :-)

2589

Studium a uplatnění / Re:Nápad na bakalářskou práci se Spring

« kdy: 15. 04. 2019, 17:53:27 »

Různé spolky, které mají jednotky až desítky členů, obvykle potřebují vést evidenci svých členů spolu s kontaktními údaji a často pak potřebují svým členům po přihlášení poskytnou něco z následujícího:

• Zobrazit kontaktní údaje ostatních členů (e-mail, telefon, Facebook, poštovní adresa…).
• Umožnit členům přihlásit se na nějakou spolkovou akci.
• Nechat členy hlasovat třeba o termínu akce nebo barvě triček.
• Vyexportovat seznam členů nebo jen některé údaje (třeba jen seznam e-mailů) do Excelu, CSV, vytisknout prezenční listinu všech členů nebo jen těch přihlášených na akci (vygenerovat PDF).
• Rozeslat členům e-mail na základě nějaké šablony (třeba s platebními údaji).

Pokud má spolek ve svých řadách nějakého programátora, obvykle na to udělá nějakou webovou aplikaci, která splní minimum toho, co je potřeba. Takže takových aplikací budou po republice desítky, místo aby byl jedna dotažená a open-source, kterou si každý přizpůsobí podle svých potřeb. A nebo se to řeší různými tabulkami posílanými e-mailem, Google tabulkou, Doodle apod.

Tak můžete začít s tou opensource aplikací, ke které se později budou moci připojit ostatní :-)

Protože má zároveň každý jiné požadavky, bylo by fajn, kdyby to bylo postavené nad zdokumentovaným RESTovým rozhraním, aby se na to případně daly napojovat další systémy. Mělo by to být multitenant, aby se to na jednom serveru dalo provozovat pro víc spolků. Může tam být implementováno přihlašování pomocí OAuth 2.0 (Facebook, Google, MojeID atd.) A různých dalších vylepšení se tam dá navymýšlet spousta.

2590

Software / Re:UDP paket server

« kdy: 12. 04. 2019, 20:18:05 »

Pokud by ten přeposílač měl pakety buferovat a na požádání je začít posílat vysílači, musí ten vysílač umět nějak o zasílání požádat – asi poslat na ten přeposílač nějaký paket, který to odstartuje. Tím odstartováním se zároveň udělá „díra“ do NATu u toho vysílače, aby NAT věděl, kam ty pakety posílat. Jenže to je vlastně to jediné, co potřebujete. Takže ten přeposílač by asi nemusel na obou stranách poslouchat, mohl by ty pakety pouze tupě přeposílat na veřejnou IP adresu NATu před tím vysílačem. Pak stačí, aby vysílač poslal správný UDP paket směrem k tomu přeposílači (který ten paket klidně může zahodit), tím si otevře dveře v NATu a začnou k němu proudit ty pakety posílané přeposílačem.

A nebo ty UDP pakety vůbec nemusíte posílat přes ten přeposílač, můžete si takhle otevřít průchod NATem na obou stranách a server s veřejnou IP adresou použít jenom k domluvě studia a vysílače na tom, jaké IP adresy mají použít. Takhle fungují různé protokoly, které umí peer-to-peer komunikaci mezi zařízeními, která jsou na obou stranách za NATem.

Hlavně, že pořád někdo tvrdí, že IPv6 vůbec není potřeba…

2591

Vývoj / Re:Zpracování XLSX v PHP/Java

« kdy: 12. 04. 2019, 19:39:35 »

Myslel jsem, že jste to formátování upravil jenom pro větší přehlednost. Pokud jsou v tom XML skutečně ty bílé znaky, jsou i v té tabulce. Pokud text má být bez mezer, musí být bez mezer i v XML. Jinak s konci řádků bych to XML raději nepoužíval, protože to je zrovna případ, kdy to Excel a Libre Office zobrazí každý jinak…

2592

Vývoj / Re:Zpracovani XLSX v PHP/Java

« kdy: 12. 04. 2019, 18:33:44 »

No ten xml se mi zdá docela čistý, nicméně mi jde o toto:

Kód: [Vybrat]

<table:table-row table:style-name="ro1">
	<table:table-cell table:style-name="ce1" office:value-type="string" calcext:value-type="string">
		<text:p>d<text:span text:style-name="T1">e</text:span>
			<text:span text:style-name="T2">fg</text:span>
		</text:p>
	</table:table-cell>
</table:table-row>

Jak z toho v obecném případě dostanete text "defg" (pomocí xpath)?

Jen tak na první pohled bych řekl, že tohle není .xlsx (Office Open XML – Microsoft Excel) – nebude to spíš .ods (OpenDocument – OpenOffice.org/LibreOffice)?

Jinak pomocí XPath z tohohle vytáhnu čistý text např. pomocí xs:string(/table:table-row/table:table-cell), přičemž to přetypování se udělá automaticky, pokud má být výstupem atomická hodnota. Takže pokud bych ten text chtěl dostat na výstup v XSLT šabloně, bylo by tam jen <xsl:value-of select="/table:table-row/table:table-cell" />. V tom je právě výhoda XML, že je obvykle možné vůbec se nezabývat věcmi, které mne nezajímají.

2593

Vývoj / Re:Zpracovani XLSX v PHP/Java

« kdy: 12. 04. 2019, 16:16:23 »

Ale na druhou stranu si musíte nastudovat, jak to xml vypadá, pokud do buňky někdo vloží třeba formátování.

Naštěstí se XLSX nesnaží XML moc znásilňovat, takže je to tak, jak by to v XML být mělo – v jednom elementu je uložená hodnota buňky, a pokud je potřeba k té buňce přidat nějaké další informace – třeba formátování nebo vzoreček – je uložená v jiném elementu nebo atributu.

2594

Sítě / Re:Bezpečný přístup na veřejnou IP přes SSH

« kdy: 12. 04. 2019, 11:05:38 »

Fail2Ban neni vsespasitelny, ale pridava urcitou uroven ochrany proti brute-force utokum

V čem ta další úroveň ochrany spočívá? Nebo-li jaký je vektor útoku, před kterým ta ochrana chrání?

Lepsi neco, nez nic

To je nesmysl. Něco neúčinného je horší než nic, protože v tom může být chyba, která v důsledku vytvoří díru do systému. A i když tam ta díra není, akorát se plýtvá energií na něco neúčinného, místo aby se dělala skutečná bezpečnostní opatření, a vyvolává to dojem, že se přece pro bezpečnost udělalo už dost. S heslem „lepší něco než nic“ můžete server chránit tak, že pod něj zakopete kořen mandragory, ale to doufám neděláte.

2595

Sítě / Re:Bezpečný přístup na veřejnou IP přes SSH

« kdy: 12. 04. 2019, 10:35:53 »

autorizace i pomocí hesla

K čemu je to dobré? Kdy nastane případ, že znáte heslo, jste ochoten jej použít a nemůžete použít klíč?

Doporučuji použít s Fail2Ban.

Já to nedoporučuji. Nevidím v tom žádný přínos, naopak je riziko, že tím zablokujete sám sebe. Osobně mi připadá zvrácený už samotný fakt, že se parsují nestrukturované logy a na základě toho se provádějí bezpečnostně citlivé operace navíc pod rootem. To ještě nikdo nezkusil udělat Fail2Ban injection?