Příspěvky

196

Server / Re:NFS na routeru

« kdy: 04. 05. 2021, 00:44:01 »

Docela me mrzi, ze misto pomoci tu clovek najde pouze vysmech. Jeden by si myslel, ze tento portal bude profesionalnejsi nez forum na zive.cz.
pokud jde o NFS server tak to mam uspesne vyzkousene mezi 2mi PC a 777 pravami. A prave pro to ze se jadna o hratky s "granatem" tak jsem doufal, ze tu najdu trochu pomoci.

Pane kolego, kdyby se to dalo nastavit jednoduchým návodem, tak by ani nebyly potřeba návody. Prostě by to bylo nastavené ve výchozích hodnotách "správně". Jenže věc se má tak, že vždy záleží na konkrétní situaci.

Z Vašeho dotazu, jak je formulován, je poměrně jasné, že Vám chybějí základní znalosti. Na to stačí trocha zkušenosti, aby to jeden z dotazu poznal. Jsou tedy tři důvody, proč Vám nikdo nechce poradit: 1) musel by Vám vysvětlit velmi širokou problematiku, 2) musel by se asi dvaceti dotazy dopídit, jak máte sestavenou síť, 3) a po radě by stejně věděl, že jste v nebezpečné situaci, protože nedokážete rizika rozpoznat.

Jinak souhlasím s dalšími kolegy, NAS na router/firewall nepatří. Firewall má činit co nejhůře překonatelnou bariéru mezi Vašimi daty a světem. Spojením obou funkcí dohromady riskujete naprosto nepřiměřeně. To riziko rozumně neumenšíte, ani kontejnery.

Omnia umí spoustu věcí, třeba routovat, třeba firewallovat, třeba NASovat. Neznamená to ale, že dává smysl některé ty funkce kombinovat. Už jen z takového nápadu, následně z (ne)popisu oprávnění, a následně z představy, že kontejner ochrání data od nařazeného OS je jasné, že víte příliš málo. Rada, abyste nekombinoval router s NASEM je ta nejlepší, kterou jste mohl dostat, opravdu.

197

Server / Re:Nginx: rozdělení serverů do samostatných souborů

« kdy: 29. 04. 2021, 17:26:50 »

Nechte si poradit.
Neměňte nic ve wordpressu.
Hlavičky máte nastavené správně, já bych jich přidal ještě víc, ale to už je jen detail.

A IP adresu řešte přes RealIP modul. S Wordpressem to funguje a používá se to na různých ISP panelech, právě proto, aby uživatel hostingu nemusel vědět a řešit, že je skrytý za reverzní proxy.

Wordpress není na proxy připravený a i když to vyřešíte tou metodou, co jste psal (a obdobnou radil i Filip), tak narazíte na problémy v doplňcích. Když použijete RealIP, na bude to fungovat hned.

Jediné, co je potřeba u RealIP pohlídat je to, aby to zpracovávalo hlavičky jen z důvěryhodné proxy, protože jinak by tam šlo podvrhnout IP adresu.

198

Server / Re:Nginx: rozdělení serverů do samostatných souborů

« kdy: 26. 04. 2021, 12:26:30 »

Proxy server to nemůže neměnit. Jedná se o IP adresu TCP/IP spojení, ta nemůže být nastavená jak vás napadne – musí být nastavená tak, aby proxy server mohl s WordPressem komunikovat.

To je pravda, ale jen z půlky. RealIP modul ji umí zase vrátit zpátky, takže aplikace pod proxy serverem si toho nemusí ani všimnout. Je to operace navíc, ale s WordPressem se stejně na výkon nehraje.

Buďto to musí podporovat Wordpress (ale co já vím tak ani v roce 2021 na to není WP připravený - jako kdyby WP autoři nikdy nepotkali proxy).

Ne buďto a nebo. Proxy server musí původní IP adresu přidat do HTTP hlaviček, WordPress si ji odsud musí vyzvednout. A vyzvedává si ji.

Jo, už jsem si s tím párkrát užil, jak spolehlivě to vyzvedává. Jednodušší mi přijde, na takový krám, použít ten RealIP modul, ušetří to ve výsledku starosti.

Tak medzi tym som nasiel funkcne riesenie, ale mohol by som to skusit aj s nastavenim tych hlavyciek.
zatial dik

Tohle bych považoval za nejméně vhodné řešení, protože nevíte, jestli to bude fungovat napříč celým WordPressem a jeho moduly. Navíc, budete to muset nosit v hlavě, a pohlídat při každém větším updatu (když se mění wp-config), abyste to přenesl.

199

Server / Re:Nginx: rozdělení serverů do samostatných souborů

« kdy: 26. 04. 2021, 11:45:19 »

Buďto to musí podporovat Wordpress (ale co já vím tak ani v roce 2021 na to není WP připravený - jako kdyby WP autoři nikdy nepotkali proxy). Obejít se to dá pomocí modulů (nevím, na čem Vám běž WP, jestli na nginxu nebo Apachi):

http://nginx.org/en/docs/http/ngx_http_realip_module.html
https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html

Tím se dá zajistit, že webserver převezme (a dál předává) IP adresu, kterou proxy předává v hlavičkách.
Ale opatrně s tím, abyste s jistotou přebíral IP adresu z důvěryhodné hlavičky. Kdyby se někomu podařilo touto cestou podstrčit IP adresu, mohl by to být bezpečnostní risk.

200

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 23. 04. 2021, 12:49:40 »

Takže, jinými slovy, z celého příspěvku jste si vybral jedinou věc a ještě jí otočil tak, aby vám vyhovovala a hodila se do vašeho pojetí světa

Kterou? Moje odpověď obsahovala příklad z ranku RDBMS, ale týká se všech zmíněných (i dalších) témat.

201

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 23. 04. 2021, 10:09:06 »

Šáhněte si do svědomí, jestli sám máte všechno v pořádku a jestli je ta nedokonalá znalost RDBMS opravdu to jediné, co nás trápí...

Snažím se vždy posoudit (neformalizovaně), jak velké mezery v které oblasti (z těch jmenovaných) a na kterém projektu mám, a volím ten kompromis co nejvíc racionálně. Snažím se udržovat si přehled, jakým směrem se projekt může ubírat a hlídat ty části, na kterých by to mohlo narazit. Na registrační formulář, pro zákazníka, který má po 20 letech činnosti pár tisíc registrací, klidně šoupnu MySQL a ORM, ale pohlídám, že se to neobjeví na projektu, kde mám po roce desítky milionů záznamů (položek) a vím, že je nutné s nimi pracovat dál. Jenže na to musíte mít aspoň ten přehled (a toho není nikdy dost, to uznávám).

Ale taky se setkávám s vývojáři, pro které je překvapením, že by nějaká i free databáze mohla dávat mnohořádově vyšší výkon, nebo vůbec netuší, že je ORM odizoluje od možnosti optimalizací, které k tomu vedou. Nevědí, že stejná databáze může úplně stejný výsledek poskytnout mnohem rychleji, když se navrhne trochu jinak. Jsou prostě naučeni jeden jediný postup, aniž by znali jeho výhody a nevýhody.

Pokud tedy nevědí, kde jaký prostor je, pak nemohou činit ani rozhodnutí.

Co tady říkám (a mám dojem, že Pavel taky) je to, že by vývojáři měli mít právě ten vhled do těch oblastí, a aby uměli vytipovat místa a chvíle, kdy je potřeba se zeptat někoho dalšího. Tedy např.: budu programovat e-shop, který bude vše feedovat do ERP systému. Je vhodné použít ORM? Vs. budu programovat e-shop s pokročilou administrací, s požadavkem na složité výstupy, napojený na dalších 12 systémů - je ORM vhodné? Jenže na to musí vědět, že takovou otázku (si) musí vůbec položit.

202

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 23. 04. 2021, 09:36:47 »

Co myslíte - kolik "developerů" tuší, že existuje tranasction isolation level?

Hůř. Kolik myslíte, že existuje developerů, kteří tuší, že existují transakce?

203

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 23. 04. 2021, 08:44:29 »

@PanVP

Já myslím, že si nikdo nedělá iluze, jak fungují práce na projektu. Jenže jde o to, že uspěchaná práce na začátku znamená 5x víc problémů později. Někdy se to může vyplatit, zejména když nepředpokládáte, že projekt bude moc růst. Ale každý by měl vědět, jakou cenu za to (za)platí.

Druhá věc je to, že pokud by programátor měl v sobě aspoň ty základy RDBMS, tak by ho to při práci vůbec nezdržovalo. Sice by nesypal z rukávu vycizelovaná řešení, ale aspoň by taky nedostával části kódu do slepých uliček. V budoucnu, až by se objevila potřeba optimalizovat, byly by aspoň nějaké možnosti.

Problém je, že hordy programátorů nemají ani tu bazální znalost, aby uměli toto rozlišení provést. Ve své neznalosti si myslí, že pracují con lege artis a vůbec netuší, že by někdy stačilo opravdu jen málo.

Programátoři, kteří přehled mají, taky dělají kompromisy. Ale činí tak uvědoměle, na základě nějakého ratia.

Naopak je smutné vidět, když programátor pracuje s blbým milionem řádků v jedné tabulce a vůbec mu nepřijde podivné, že nějaké jednoduché zpracování trvá celé sekundy... Pokud je to na webu, pak ještě tlačí na admina, aby posouval limity na běhy scriptů a timeouty na http serveru a proxy na desítky sekund. Pak, když server začne nestíhat (protože není ani chráněný limity a timeouty), tak zákazník ječí ještě víc, než když nefunguje jen ten jeden formulář. Pak začne ten pravý boj. Zákazník ječí, a management hledá viníka. Admin namítá, že o problémech věděl a upozorňoval na nevhodný návrh zavčas, vývoj namítá, že mu nikdo nedal čas a prostředky to udělat lépe. Otázku, jestli za tím vším nestojí jen úplně obyčejné neznalosti, už management nedokáže posoudit (obvykle). A aby se něco udělalo, tak se většinou spíš posílí železo, doprogramují se (navíc!) nějaké aplikační zrychlováky, čímž se problém úspěšně zažene do kouta, kde na bobečku čeká na vhodnou příležitost, aby o sobě zase dal vědět.

Kritika, že by vývojáři měli znát aspoň možnosti RDBMS, je na místě!

204

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 21. 04. 2021, 16:54:10 »

Chtěl bych doma mít jednoduchý web, IP kamery a přístup do NextCloudu. Poběží to všude?

Musíte si nejprve ověřit u softwaru / hardwaru, který chcete užívat, jestli je schopný pracovat za překladem (NAT). Většinou ano, ale jistota to není.

Pak si musíte u poskytovatele zjistit, jestli pevnou veřejnou IP adresu nabízí (patrně bude chtít připlatit) a jakým způsobem ji nabízí (směruje, NAT 1:1, PPPoE, ...).

A nakonec musíte tyto dvě informace proti sobě porovnat.

205

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 21. 04. 2021, 16:49:08 »

Já to rozlišování stavím na tom, jestli je objektivně splněna zákazníkova potřeba.

Což je v rovině pouhého tvrzení a pochybnosti už jen zde, v této diskusi zazněly z vícero stran. S objektivitou to nemá nic společného.

Představte si jakýkoliv výrobek či službu, kterou zákazník reklamuje, a reklamace bude zamítnuta s tím, že 90 % zákazníků to stačí a nestěžují si... Super...

206

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 21. 04. 2021, 16:22:29 »

Ne, NAT není nevyhnutelný. NAT používají ISP jen proto, že je pro ně levnější, než pořízení dostatečného množství IPv4 adres. Stále existují ISP, kteří přidělují veřejné IPv4 adresy, takže technicky to evidentně řešitelné je.

Počkejte, bavíme se o zákaznících, kteří si připlácejí za přidělení veřejné IP adresy - tj. pro takového zákazníka musí ISP tu adresu mít.

Obecně nevyhnutelný je, každý počítač na světě nemůže dostat vlastní, pravděpodobně by to nevyšlo ani počítáno na přípojky. NAT musíme počítat jako nevyhnutelný.

207

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 21. 04. 2021, 15:54:56 »

Filipe, nevyhnutelné neznamená podle možností ISP, ale podle obecných možností v oboru.
Je to úplně stejné, jako když e-shopy porušují GDPR zbytečným uchováváním osobních informací s tím, že jejich systém to jinak neumí.

NAT je nevyhnutelná výjimka ze směrování IP.
Z výjimky (ať už je v zákoně, nebo v jakémkoliv jiném kontextu) se nesmí stát extenzivním užíváním pravidlo.

Ke zbytku už nemá smysl opakovat argumenty.

208

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 21. 04. 2021, 14:46:15 »

@Logik

Já myslím, že už jsme se k podstatě problému dostali, mezi spoustou textu to zaznělo:

• NAT je nutná technologie ve světě, kde není dostatek IP adres.
• NAT musí zasahovat do provozu, nezřídka mění i payload, některé protokoly nepropouští.
• Pokud si zákazník platí za vyhrazenou veřejnou IP adresu, pak není nevyhnutelné používat NAT a není potřeba zasahovat do provozu.
• Zákazník může spravedlivě očekávat, že když si za vyhrazení IP adresy platí, nebude mu ISP do provozu zasahovat stejně, jako kdyby si neplatil.
• Toto očekávání je oprávněné. (neshodujeme se)
• Pokud ISP využívá NAT 1:1, tak zasahuje do provozu zbytečně a svévolně.
• Důvod, proč se to tak dělá, je snaha ISP snížit svoje náklady.
• Pokud o tom zcela jasně neinformuje, klame zákazníka.
• ISP tím získává unfair výhodu proti konkurentům, kteří ctí zásadu nezasahovat do provozu, pokud to není nezbytné.

Argument Filipa je, že je preference zákazníka, raději baštit obarvené piliny, než jíst párek s masem. Já namítám, že zákazníci, na rozdíl od uzenin, nemají často ani představu, že dostávají místo služby šmakuládu, a taky namítám, že implementovat např. PPPoE by se na ekonomice ISP projevilo pod hranicí rozlišitelnosti. (A expresivně to nazývám leností a šmejdstvím)

209

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 21. 04. 2021, 11:56:15 »

V reálu je databáze součástí celého řešení a troufnu si tvrdit, že aplikační část bývá podstatně složitější než úkoly prováděné databází. Budu-li honit maximální výkon s minimálními požadavky na HW, budu muset optimalizovat umístěním hodně logiky a výpočtů do stored procedures. Pokud to nemusím hrotit, budu se maximálně snažit udržet aplikační logiku v jednotném prostředí, nad kterým má plnou kontrolu IDE vývojářů (debugování, trasování, snadný refaktoring). Ano, třetí strana bude muset přistupovat přes aplikační API, ale to se obvykle stejně vytváří i z řady jiných důvodů. Pro mě je DB konzistentní storage, ideálně hodně rychlý pro složité joiny, ale aplikační logiku (tedy právě třeba ty zmiňované výpočty) chci držet ve zdrojáku aplikace, pokud mi to požadavky na výkon dovolí.

Volba míry abstrakce na každé úrovni se liší od projektu, o tom žádná. Přenést logiku aplikace do procedur na SQL serveru možné je, ale nebývá výhodné ji tam přenášet moc.

Spousta systémů ale funguje tak, že kromě hlavní aplikace, přistupuje k datům ještě další horda menších systémů. Některé feedují data, jiné je dolují. Ta část logiky, která je společná pro všechny tyto cesty, se právě může hodit přenést do databáze. Nemusí to být rovnou procedury, k tomu slouží pohledy a pravidla. Pokud např. záznamy nemažete, ale pouze příznakem zneplatňujete, nabízí se rovnou vytvořit view, které poskytuje pouze platné záznamy, a logiku toho, co je platný a co zneplatněný záznam pak nemusíte opisovat do mnoha (sub)systémů znovu a znovu. To ušetří starosti, umožní patřičný vhled do operací (kvůli rozhodnutí o indexech) apod.

Stejně tak se hodí, pokud lze definovat co pro celý systém znamenají "konzistentní data", aby to databáze hlídala. Něco jde řešit prostě přes constraints, něco ale vyžaduje složitější logiku napříč vícero tabulkami. Tam pak pomohou trigger procedury. Typickým příkladem z praxe je počítání DPH na dokladech. Systémy to často hlídají v UI, ve formulářové logice. Na úrovni databáze není hlídaná konzistence položek, sazeb DPH, výpočtů, zaokrouhlení - ačkoliv to jsou pravidla určená předpisy. Pak se stává, že sice hlavní aplikace přes UI pohlídá, aby data byla správně, ale jiný (sub)systém, který např. importuje data z jiného vzdáleného systému už tyto kontroly neprovede, nebo je provede podle trochu odlišných pravidel. Pak máte v databázi guláš - otevřete importovaný doklad v UI, a při uložení se Vám změní hodnoty, protože UI si je hlídá samo. Pak se programují různé ohejbáky, aby UI nezasahovalo do importovaných dat, tedy někdy provádělo kontrolu a jindy ne, ... a přitom by stačilo, aby nekonzistentní data v DB vůbec nesměla existovat.

Takové - zmíněné - triggery samozřejmě taky hned odhalí slabá místa. Např. časté lockování přístupů. Jenže to není chyba, to je přínos. Ty samé locky, nebo kontroly, by pravděpodobně musela vykonávat i aplikace - a pokud je nedělá, je to indicie, že ve zpracování existuje díra (která se v praxi může projevit jen jednou za uherský rok - ale o to hůř se pak hledá).

Když se to takto nedělá, tak sice programátoři ušetří spoustu přemýšlení a řešení a času, ale v případě problémů to spadne na admina. Ten obvykle zase nemá přehled o aplikační logice a záměru, takže má velmi omezené možnosti to vyřešit, nebo navrhnout řešení.

210

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 21. 04. 2021, 10:59:52 »

@registrovany123

Pavel určitě odpoví, ale napíšu i já.

Denormalizace je svůdná praktika. Na jeden partikulární problém to může být efektivní řešení. Odtrhnete si data a přestanete na ně čekat, protože jsou zablokovaná.

Ta stinná stránka je přesně to, co popisujete. Denormalizace, pokud má být funkční, předpokládá, že vývojář neudělal chybu v úsudku. Může se lehce stát, že odtrhne data, která v důsledku jiných operací přestanou být konzistentní. To pak musíte pohlídat na aplikační úrovni, a to Vás opravdu může stát víc, než si dát databázi do pořádku. A jsme znovu na začátku: musí být v týmu někdo, kdo ten správný úsudek má. Pokud takového člověka v týmu máte, pak se jeho znalost dala rovnou využít k tomu, abyste se vůbec nedostal do stavu, kdy o denormalizaci uvažujete. Je to uzavřený kruh.

Osobně si myslím, že je jednodušší v týmu vypěstovat určité základní znalosti, co se dá očekávat od techniky. Programátor nemusí znát hluboce RDBMS, ale měl by rozpoznat moment, kdy se má poradit s kolegou, který je má.

Když se to nedělá (průběžně), tak se projekt může dostat do stavu, kdy už není jiná možnost, než spoustu práce zahodit a celé části přepsat znovu. To nikdo nechce. Ani zadavatel, který za to platí - tomu těžko vysvětlíte, že jste mu celý rok šli na ruku, aby měl úpravy hotové rychle, ale že po roce se velká část práce může hodit do koše a musí se refaktorovat. Je jen málo zadavatelů, kteří jsou schopni kvalifikovat důsledky rychlého vs. systematického vývoje, ale pochopitelně i takoví existují. Někdy je opravdu obchodně výhodnější "psát na prasátko" s vědomím, že se to později refaktoruje.