Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 63 64 [65] 66 67 ... 375
961
Vývoj / Re:XSLT 1.0 - porovnávání v cyklu
« kdy: 14. 10. 2021, 15:38:04 »
Má to být tak, že za duplicitu se považuje, když je stejné Qty a Date, nebo je duplicita, když je stejná alespoň jedna ze dvou hodnot?

962
Vývoj / Re:XSLT 1.0 - porovnávání v cyklu
« kdy: 13. 10. 2021, 22:04:33 »
Takhle, vždycky zapomenu, jak se chovají negace spolu se sekvencemi:
Kód: [Vybrat]
/Main/Payload[@id='A2']/Data/row/Qty[not(. = /Main/Payload[@id='A1']/Data/row/Qty)]

963
Vývoj / Re:XSLT 1.0 - porovnávání v cyklu
« kdy: 13. 10. 2021, 21:31:07 »
To se nedělá pomocí cyklu ale pomocí podmínky […]. To vaše zadání není úplně podrobné, ale ten XPath výraz může být třeba nějak takto:

Kód: [Vybrat]
/Main/Payload[@id='A2']/Data/row/Qty[. != /Main/Payload[@id='A1']/Data/row/Qty]

964
Server / Re:Šifrování se vzdáleným přístupem
« kdy: 13. 10. 2021, 20:41:09 »
Přes management (ten nevím jak se backdooruje, ale slyšel jsem, že v nich bývají úplně neuvěřitelné díry)
Což znamená získat od hostingu druhý síťový port, druhou veřejnou IP adresu nebo alespoň přesměrování portu… Pokud se objednává na počet U nebo rovnou celé racky, bude se řešit i management síť. Já jsem si ale pod dotazem představil takovou tu polici, kde směska nejrůznějších towerů, RPi, „set-top-boxů“ apod., a tam asi management port v ceně nebude.

Myslím, že s takovýmto zabezpečením bude nejsložitější na celé věci sehnat detailní plány jaderné elektrárny, které na ten server uložíte – aby tak silné zabezpečení mělo nějaký smysl ;-)

965
Server / Re:Šifrování se vzdáleným přístupem
« kdy: 13. 10. 2021, 15:49:55 »
Ještě se dá jednoduše přidat 2fázová ochrana OAuth, takže jen heslo k přístupu nestačí a je nutné použít i kód z mobilu (je třeba si udělat zálohu instalačního kódu při ukládání do telefonu).
To ale nijak nezvyšuje bezpečnost šifrovaných dat. Tím zabezpečíte přístup přes SSH nebo login, ale pokud má někdo přístup k fyzickému disku, prostě ho přimountuje do svého systému a je mu úplně jedno, co by dělal systém na tom disku, kdyby ho nabootoval.

966
Server / Re:Šifrování se vzdáleným přístupem
« kdy: 13. 10. 2021, 15:16:59 »
Ano, jde to, je to naprosto běžná věc. Úplně jednoduché řešení je takové, že se nastartuje jenom nejnutnější základ systému (a s ním i SSH) z nešifrovaného disku, vy se připojíte přes SSH, zadáte heslo a teprve tím se připojí disk šifrovaný disk s daty. Dost informací na jedné stránce najdete ve wiki ArchLinuxu: Data-at-rest encryption (neznamená to, že musíte použít Arch – jenom jejich wiki je skvělá a obsahuje spoustu informací). Nebo zkuste rovnou googlit „debian system encrypt“, najdete spoustu článků, které popisují krok za krokem, co je potřeba udělat.

Takže jde i o to, aby heslo nebo jeho hash po restartu nezůstalo v nějaké cache.
Ukládat hash hesla do cache by bylo k ničemu. A při restartu se paměť počítače smaže, takže heslo v žádné cache nezůstane.

967
Server / Re:Jak co nejjednodušeji udělat záložní MX server?
« kdy: 13. 10. 2021, 15:05:54 »
jestli není lepší, že po dni a půl odesílatel dostane upozornění, že adresát email nepřijmul nebo že zpráva leží na cestě.
Právě že je docela pravděpodobné, že žádné takové upozornění nedostane. Dneska je možné posílat nedoručenky jedině v případě, že jste si hodně jistý tím, kdo je skutečný odesílatel e-mailu.

Ono to lze pojmout i takto, pokud firma nedokáže za den nahodit mailserver ze záloh, asi by si neměla zprovozňovat záložní SMTP jako řešení potenciálního problému.
Jenže ono to právě není takhle jednoduché. Klidně můžete server za den obnovit ze záloh, ale pokud máte v DNS MX záznam s platností 7 dní a vede na starou IP adresu, bude vám to k ničemu. Proto jsem psal o tom, že nejdůležitější je mít předem rozmyšlené a předem připravené, jak bude takové záložní řešení vypadat. Teprve z toho vyplyne, jestli záložní řešení je „umím přehodit příjem pošty na jiný server dřív, než se e-maily začnou ztrácet z front“, nebo jestli záložní řešení je „stejně potřebuju někde trvale běžící SMTP server, tak proč ho rovnou nezveřejnit v DNS?“

Mimochodem, e-mail dneska slouží jako hlavní identifikační prostředek. Takže osobně nepovažuju za největší problém to, že nějaká obchodní poptávka dorazí až za den a možná na ni jiná firma odpoví dřív. Větší problém je to, že zaměstnanci mé firmy nebudou moci resetovat zapomenuté heslo do nějakého systému, nebudou se moci někam zaregistrovat apod. Nebo jim nebudou chodit nějaké notifikace, že mají schválit odchozí platbu, že je nějaký systém přetížen apod. To může způsobit daleko vážnější problém.

968
Server / Re:Jak co nejjednodušeji udělat záložní MX server?
« kdy: 12. 10. 2021, 16:38:27 »
SMTP samo o sobě je navrženo tak dobře, že s výpadkem na několik hodin se doslova počítá. U našeho mailserveru (shameless plug https://poste.io) se doručuje až třináctkrát, poslední pokus je po jeden a půl dni. Až teprve potom to vzdá a vygeneruje bounce. Ostatní MTA to mají obdobně.
Já bych záložní mail server úplně nepodceňoval. Jeden a půl dne není zas tak dlouho, vzpomeňte na požár datacentra OVH.  Záložní mail server třeba nemusí být aktivní, nemusí být uveden v DNS – ale měl bych být schopen náhradní server během pár hodin zprovoznit a přesměrovat na něj příchozí provoz. Samozřejmě že aktivní server, na který směřují MX záznamy  nižší prioritou, tohle splňuje a může to být lepší řešení, než něco zprovozňovat až v případě problémů.

Ale pořád platí to nejdůležitější pravidlo – všechny záložní poštovní servery musí být při příjmu e-mailů stejně přísné, jako hlavní server. Tj. musí odmítat neexistující adresáty, musí používat stejnou antivirovou a antispamovou ochranu, pokud používáte greylisting, musí být i na záložním serveru. Jakmile bude záložní server v něčem benevolentnější, nemusíte tu přísnější ochranu mít ani na hlavním serveru, protože útočníci vám to budu cpát skrze ten záložní. (A navíc si tím jenom podstatně zkomplikujete život, protože nebude váš hlavní server odmítat e-maily přímo spammerovi, ale bude je odmítat vašemu záložnímu serveru. Takže problémy a rostoucí frontu nebude řešit spammer, ale vy.)

Takže jestli potřebujete záložní server, nebo z toho rovnou uděláte load balancer, nebo jestli vám stačí studená záloha, t oje vaše rozhodnutí, to vám asi nikdo neporadí, bez detailní znalosti vašich podmínek. Ale počítejte s tím nejdůležitějším pravidlem uvedeným v předchozím odstavci. Takže pokud nedokážete databázi uživatelé replikovat i na záložní server, záložní server vůbec nedělejte. (Mimochodem, ta databáze uživatelů nemusí být plnohodnotná databáze a nemusí být každou milisekundu shodná s hlavní databází. Pokud to jinak nejde, seznam uživatelů vysypaný do textového souboru a synchronizovaný jendou za 5 minut přes rsync je použitelné řešení. Mít na záložním serveru doménový koš není řešení.)

969
Server / Re:Jak co nejjednodušeji udělat záložní MX server?
« kdy: 12. 10. 2021, 09:14:11 »
Promiňte, jak říkám, spam se nerozloží, ale zdvojnásobí.
To těžko. Spammer nemá důvod ten samý e-mail posílat stejnému adresátovi přes jiný server, když místo toho může poslat e-mail někomu jinému.

970
Server / Re:Jak co nejjednodušeji udělat záložní MX server?
« kdy: 11. 10. 2021, 21:32:51 »
To není nutné, odesílající servery to zkouší poslat znovu , tuším 5 dní
Není to žádná globální konstanta. Je na konfiguraci každého klienta (to, čemu vy říkáte „odesílající server“), zda a jak dlouho bude držet e-maily ve frontě a zkoušet je odeslat znovu. Třeba spammeři to často znova vůbec nezkouší ;-)

971
Server / Re:Jak co nejjednodušeji udělat záložní MX server?
« kdy: 11. 10. 2021, 17:15:49 »
Neodmítat poštu pro neexistující uživatele na záložním serveru dnes prakticky nejde. Spousta spammerů toho využívala, že záložní servery tohle nedělaly a rovnou směřovala e-maily na záložní servery. Když záložní server přijme, má zodpovědnost za jeho doručení. Pokud schránka na primárním serveru neexistuje, má poslat odesílateli e-mail o nedoručení – jenže e-mail odesílatele bude obvykle zfalšovaný, takže e-maily o nedoručení budete jen obtěžovat nevinné lidi. Fakticky půjde z vaší strany o spam – a spammeři s tím samozřejmě počítají a to podstatné uvádějí do úvodní části e-mailu, která je v odpovědi o nedoručení citovaná.

Pokud byste chtěl zprávy pro neexistující adresy přijmout a pak zahodit, nedozví se zase odesílatel, který udělal překlep, že zadal špatný e-mail.

Je potřeba počítat s tím, že záložní MX server se u regulérního e-mailu dostane ke slovu akorát v případě, kdy budete mít dlouhodobý výpadek na primárním serveru. Protože krátkodobý výpadek primárního serveru překlene regulérní e-mail tak, že ho u sebe podrží odesílatel ve frontě a zkusí ho odeslat za pár minut znovu.

972
Sítě / Re:Wifi cez 4 pokoje
« kdy: 10. 10. 2021, 10:08:24 »
Z hlediska času a věnovaného úsilí za jeden víkend je kabel nejnáročnější řešení, ale až budete za půl roku kupovat třetí router a počtvrté se ptát v diskusi, jak ten signál vylepšit, zjistíte, že ten drát by bával byl i na ten spálený čas levnější. Pokud si ty díry neumíte udělat sám, někoho si na to pozvěte, vyjde to pořád levněji než experimentování s WiFi routery.

Pokud byste se tomu vrtání chtěl za každou cenu vyhnout a máte v obou pokojích zásuvky na stejné fázi, můžete zkusit ten přenos přes vedení vysokého napětí Power Line. Pokud vím, zkušenosti jsou s tím různé, někdo si to pochvaluje, někdo s tím má problémy.

973
Sítě / Re:Wifi cez 4 pokoje
« kdy: 09. 10. 2021, 11:04:51 »


Pánové, oběma díky, že jste opravili to, co jsem já napsal nepřesně nebo i špatně – s tím výkonem jsem to zmatlal dost  :( Každopádně pokud má být pokrytý jen první a čtvrtý pokoj, dal bych v tuto chvíli AP do těch dvou pokojů a propojil bych je drátem. Husí krk bych do těch příček mezi pokoj dal i proto, až zjistíte, že chcete přidat nějaké zařízení i do některé místnosti uprostřed :-)

974
Sítě / Re:Wifi cez 4 pokoje
« kdy: 09. 10. 2021, 10:10:37 »
Záleží především na tom, z jakého materiálu jsou příčky mezi těmi pokoji. Pokud je to železobeton nebo sádrokarton zavěšený na kovovém rámu, bude to WiFi signál dost tlumit. Pokud je to cihlová zeď, útlum je daleko menší.

Síla WiFi signálu se měří v dB (decibely). Nicméně výkon vysílání je tam omezen normou (pro vnitřní použití je limit nižší), kterou běžná zařízení nedovolí překročit. U venkovních instalací se to řeší směrovými nebo sektorovými spoji – ten povolený výkon nevysíláte zbůhdarma na všechna strany, ale soustředíte ho jen do určité oblasti nebo relativně úzkého paprsku. Nicméně pro interní použití to moc smysl nedává. Lepší WiFi routery umí to, že umí signál vyzařovaný anténou směřovat tam, kde jsou nějaká zařízení. Není to tak přesné zacílení jako u směrové antény, ale signál zařízení by to mělo zlepšit.

Nicméně pokud teď v tom čtvrtém pokoji signál nechytíte vůbec, nebo je velmi slabý a je problém s připojením, snažil bych se WiFi úplně vyhnout a natáhnout tam drát. Je to pracnější, ale pak vám to bude spoustu let sloužit a nebudou s tím žádné problémy. Pokud jsou příčky z nějakého materiálu, který WiFi signál ruší, budete s tím mít jenom problémy. Možná teď najdete nějaký router, se kterým to bude fungovat, ale ten za pár let odejde a budete to řešit znovu. Protažení jednoho síťového kabelu není zas tak pracné, pak se jenom na konec nacvakají koncovky. Nebo pokud je to aspoň trochu možné, udělejte prostupy mezi pokoji trochu větší, dejte tam ten nejtenčí husí krk, kterým projde kabel i s koncovkou. Jednak nebudete muset řešit nacvakávání koncovek, koupíte kabel už hotový. A za druhé i kdyby bylo potřeba ten kabel za deset nebo za třicet let vyměnit, jenom tenhle kabel vytáhnete a zatáhnete tam nový.

975
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 02. 10. 2021, 14:56:06 »
Tak není třeba se zabývat okrajovými případy, co myslíte?
Já myslím, že když nemůžeme vyloučit, že se jedná o ten okrajový případ, tak je dobré se tím zabývat – zejména když chcete na základě toho někoho obvinit, že něco dělá špatně nebo dokonce protizákonně.

Jinak pro vaši informaci, v ČR bylo dost „wifinářů“, malých ISP, kteří poskytovali připojení k internetu pro pár klientů někde v místě, kam se velkým poskytovatelům nechtělo. Často jenom koupili konektivitu od většího ISP a rozvedli to wifinama po nějaké vesnici, jejich vlastní infrastruktura byla minimální, někteří právě neměli ani vlastní DNS resolvery. Případně ti, kteří  si zakládali na tom, že jsou skutečný ISP, měli alespoň jeden DNS resolver a jako záložní nastavovali něco jiného.

Na vašem místě bych se moc nechlubil tím, že za „reálný svět“ považujete jen několika málo případů, se kterými jste se osobně setkal, a zcela ignorujete zkušenosti jiných lidí.

Stran: 1 ... 63 64 [65] 66 67 ... 375