Příspěvky

3901

Sítě / Re:Nepřetržité DoS útoky ze stejné MAC adresy

« kdy: 01. 07. 2017, 13:43:28 »

Včera to byl pro změnu synflood, dřív to byl i pingflood. Tak či onak, potřeboval bych nějak rozklíčovat kdo/kde je zdroj toho svinčíku, t.j. odhalit nějak tu MAC adresu. U sebe doma ji na 100% nemám.

To si musíte vybrat. Buď chcete odhalit příčinu, nebo chcete věřit ničím nepodloženým tvrzením „doma ji na 100 % nemám“.

Pokud je možnost na tom routeru spustit tcpdump nebo něco podobného, nechte naslouchat dvě instance, jednu na vnitřním rozhraní, jednu na vnějším, a nechte zachytávat ICMP pakety. Tak zjistíte, zda to jde z internetu nebo z vnitřní sítě. Pokud to router neumožňuje, asi nezbyde než před něj dát nějaký počítač s Linuxem a pakety odchytávat tam. Případně pokud máte řiditelný switch, můžete na něm použít zrcadlení portů.

3902

Sítě / Re:Nepřetržité DoS útoky ze stejné MAC adresy

« kdy: 30. 06. 2017, 11:02:19 »

Z toho ale není vůbec jasné, jestli ten paket pochází z vnitřní sítě nebo z internetu, ani proč router usoudil, že se jedná o Smurf útok. On to taky mohl být jeden paket se špatnou zdrojovou adresou…

3903

Vývoj / Re:Sdílení zdrojových kódů mezi různými počítači

« kdy: 30. 06. 2017, 07:27:13 »

Pokud se vám zdá Git složitý, můžete zkusit začít Mercurialem, který je o něco jednodušší, a Git se naučit až později. Na druhou stranu, dříve jsem Mercurial aspoň občas potkal, ale mám pocit, že teď už ho Git úplně převálcoval. Každopádně na Git i Mercurial můžete použít BitBucket, máte tam zdarma i privátní repository a máte to uložené na centrálním serveru, ze kterého budete jen jednotlivé pracovní stanice synchronizovat. Nevím, jak vypadá Git nebo Mercurial klient v NetBeans, každopádně jak už tu padlo, můžete pro Git i Mercurial použít grafického klienta SourceTree, který má pro BitBucket speciální podporu.

Používat to pak můžete úplně primitivním způsobem – naklonujete repository, před začátkem práce pomocí pull zaktualizujete lokální repository, po dokončení práce commitnete a pushnete změny do vzdáleného repository. Nemusíte řešit žádné branche nebo tagy, ani pullrequesty, když budete na projektu dělat sám, nemusíte řešit žádné konflikty, rebase nebo patche. Prostě jen pull a commit+push

3904

Sítě / Re:Nepřetržité DoS útoky ze stejné MAC adresy

« kdy: 29. 06. 2017, 16:12:21 »

Já si nemyslím, že jsou to útoky ze sítě providera. Je to SOHO router, něco blokuje a tuhne kvůli tomu – já bych si tipnul, že router má problémy sám se sebou, případně je to nějaké smetí v domácí síti.

Pokud chcete problém opravdu vyřešit, začal bych tím, že napíšete, o jaký se jedná router, jak jste přišel na tu MAC adresu a jak jste přišel na to, že jde o útoky Smurf, Synflood.

3905

Sítě / Re:Jak lépe navrhnout síť - proxy

« kdy: 27. 06. 2017, 14:13:08 »

Konfiguraci prohlížeče zajistíte pomocí WPAD (přes DHCP nebo DNS). Prohlížeč si pak z uvedené adresy stáhne Proxy auto-config –JavaScriptový soubor s funkcí FindProxyForURL, která dostane jako parametry URL a hostname, a vrátí způsob,  jak má prohlížeč pokračovat (zda má použít přímé spojení nebo proxy server, a který proxy server). U vzdálených pracovišť tedy v tomto souboru rozhodnete, zda má jít prohlížeč přímo (přes vzdáleného ISP) a nebo  přes váš proxy server.

3906

Server / Re:Podmínky konzistence dat v databázi

« kdy: 20. 06. 2017, 14:09:02 »

Pokud je to obecná otázka, nedá se na ní podle mne odpovědět, protože u obecných transakčních systémů znám ještě méně předpokladů, než u ACID. Navíc „stupeň izolace serializable“ podle mne dost jasně odkazuje k ACID relačním databázím. A pokud by „stupeň izolace serializable“ v té otázce zahrnovalo třeba i „read commited“ a „read uncomitted“, nechápu, proti čemu by se to vlastně vymezovalo – co by měl být ten stupeň izolace, který konzistenci nezajistí.

3907

Server / Re:Bind a "scripting engine"

« kdy: 20. 06. 2017, 11:54:23 »

Nenapsal jste, zda jde o autoritativní server nebo resolver. Knot Resolver je možné skriptovat v Lua, Knot DNS (autoritativní server) má možnost přidávat moduly.

3908

Server / Re:Podmínky konzistence dat v databázi

« kdy: 19. 06. 2017, 21:48:05 »

Mimochodem, na tu první otázku tu bylo několik odpovědí, že správná odpověď je 1), 2) nebo obojí. Mohl by mi někdo z těch, kdo tak odpověděli, vysvětlit, co se podle něj myslí tou „konzistencí dat“? Já si pod tím představuju C z ACID, a to to evidentně není, protože to zajišťují i všechny ostatní běžné úrovně izolace transakcí. Napadá mne ještě aplikační konzistence dat, ale to zase nezajistí žádná úroveň izolace transakcí, to musí zajistit správně napsaná business logika. Nebo jinak – co z toho, co odlišuje úroveň izolace transakcí serializable dejme tomu od repeatable read nazýváte „konzistencí dat“?

3909

Server / Re:Konzistencia dat - databaza

« kdy: 19. 06. 2017, 14:15:09 »

Jistě se shodneme na tom, že tu transakci má na starosti business vrstva a je vcelku jedno, zda se nachází v databázi nebo v aplikaci. Výsledkem business vrstvy je provedení nebo odmítnutí požadavku.

Na tom se shodneme. Pro původní dotaz je ale jedno, kdo má na starost transakci a kde se ta transakce nachází. Podstatné je, že když máte dvě transakce, jedna maže jeden konkrétní záznam, druhá ten samý záznam aktualizuje (a když se aktualizace nepodaří, např. protože záznam neexistuje, tak transakce selže a odroluje se), záleží na pořadí provedení transakcí. Není podstatné, kdo kontroluje, zda se aktualizace provedla či neprovedla a případně způsobí odvolání transakce.

3910

Server / Re:Konzistencia dat - databaza

« kdy: 19. 06. 2017, 13:05:04 »

Teď je otázkou, zda taková transakce má být v databázové nebo v aplikační vrstvě. Většinou se to tlačí přes aplikační vrstvu a mohou z toho vznikat docela vážné kolize.

"Promáchnutí naprázdno" samozřejmě v databázi chybou není. Je na business vrstvě, aby z toho chybu udělala, provedla rollback a vygenerovala patřičnou výjimku.

Transakce je jenom jedna a jde přes aplikační i databázovou vrstvu. Nepsal jsem, že „promáchnutí na prázdno“ je chybou v databázi (i když může být, pokud bude logika v databázových procedurách). Ale i když ten výsledek kontroluje business vrstva, dělá to v rámci běžící transakce, a když zjistí, že došlo k chybě, transakci odroluje. Z pohledu databáze j eto tedy stále jedna transakce, ve které dojde k chybě a je odrolována – to, že tu chybu musí do transakce z venku polsat aplikace je jen implementační detail. Teoreticky se to samozřejmě dá řešit i mimo transakce, tedy řešit transakčnost až v aplikaci, ale většinou k tomu není důvod a celou věc by to jen zbytečně zkomplikovalo.

3911

Server / Re:Konzistencia dat - databaza

« kdy: 19. 06. 2017, 12:24:48 »

Mimochodom aspon jedna odpoved musi byt spravna.

Možná v kontextu daného předmětu, kdy se „konzistencí dat“ myslí bůhvíco. Pokud se to zadání vezme jako obecné tvrzení o databázích, není pravdivá ani jedna odpověď, protože konzistenci dat (z hlediska interních databázových struktur i z hlediska omezení definovaných nad daty) musí zajišťovat ACID databáze sama o sobě, bez ohledu na úroveň izolace transakcí. Kdybyste zvolil izolaci transakcí třeba „repeatable read“ a při vhodné konstelaci by se vám podařilo zapsat dva řádky se stejnou hodnotou unikátního sloupce, nebo dokonce poškodit interní strukturu databázových souborů, byla by ta databáze k ničemu.

Samozřejmě databáze nemusí zajišťovat plný ACID (zejména u NoSQL databází je to oblíbené), ale to by pak muselo být součástí zadání, jaké předpoklady vlastně databáze splňuje.

Tu to podla mna staci atribut v PREDMETe, cize D, nie?

Určitě ne, vždyť je to známka studenta z předmětu. Kdybyste známku zapisoval k předmětu, bude ta známka jedna pro předmět, tedy všichni studenti by měli stejnou známku. Správně je tedy C, ale mohlo by být i A.

Mame zadanu relaciu tvorenu spojenim dvoch tabuliek T1 a T2. Primarny kluc tabulky T1 je reprezentovany atributom PK, odpovedajuci cudzi kluc tabulky T2 je reprezentovany atributom FK. Definicia referencnej integrity zaisti, aby pri zmene hodnoty primarneho kluca tabulky T1 doslo aj k prislusnej zmene hodnoty cudzieho kluca tabulky T2.
A: je vlastnostou primarneho kluca, a teda je sucastou definicie tabulky T1
B: je vlastnostou cudzieho kluca, a teda je sucastou definicie tabulky T2
C: vzhladom k tomu, ze je vlastnostou paru tabuliek T1 a T2, nemoze byt sucastou definicie jednotlivych tabuliek T1 a T2

Tuto si nie som vobec isty, s databazami som doteraz na bakalarskom studiu do styku nedosiel, a tieto otazky v prijmackach nie su pre mna velmi jednoduche. Ale dal by som C.

Je to vlastností cizího klíče – při definici cizího klíče je možné uvést klauzuli ON UPDATE nebo ON DELETE.

3912

Server / Re:Konzistencia dat - databaza

« kdy: 19. 06. 2017, 12:03:59 »

Je to takový způsob provedení transakcí, že výsledek je ekvivalentní tomu, kdyby byly transakce spuštěné za sebou v libovolném pořadí. Čili např. jedna transakce nastaví hodnotu "surname" v řádku 123 na "Prýmek" a druhá hodnotu "name" v řádku 456 na "Mirek". Je jedno, jestli je spustím po sobě jako A,B nebo B,A, nebo je pustím paralelně. Nijak se vzájemně neovlivňují.

Nikoli. Výsledek je ekvivalentní tomu, jako by transakce byly spuštěné postupně, tj. nejprve začne jedna, skončí, a teprve po ní začne druhá. Ale neznamená to, že nezáleží na pořadí. Pokud budou obě transakce měnit příjmení, tak samozřejmě na pořadí transakcí záleží a zvítězí ta druhá. To, že na pořadí záleží, není vlastností izolace transakcí, ale závisí to na tom, co ty transakce provádějí. Klidně můžete spustit transakce s izolací serializable, které dělají takové změny v datech, že na pořadí záleží.

Druhá transakce neskončí chybou. Prostě se inkrementace neprovede, protože není na čem, ale chyba to není.

Chyba to samozřejmě je – když aplikace chce updatovat jeden řádek, musí si zkontrolovat, že se jeden řádek updatoval, a pokud tomu tak není, transakci odroluje. Představte si to na klasickém příkladu s bankovními účty – v jedné transakci 1. update sníží zůstatek na účtu odesílatele a 2. update zvýší zůstatek na účtu příjemce. Pokud druhý update „promáchne na prázdno“, protože účet příjemce byl mezi tím zrušen, musí se celá transakce odrolovat – jinak by došlo k ukázkové chybě, že peníze byly z účtu odesílatele strženy, ale následně zmizely v černé díře.

3913

Server / Re:Konzistencia dat - databaza

« kdy: 19. 06. 2017, 09:40:15 »

Pokud se jedná o klasické ACID transakce, není správně ani jedna odpověď. To „C“ v „ACID“ znamená „consistency“,  konzistenci dat tak musí zajišťovat samotná databáze (tak, jak je konzistence definována ve struktuře databáze – pomocí cizích klíčů, unikátnosti a dalších omezení). Pokud je myšlena konzistence dat na úrovni aplikace, to nezachrání ani sériové zpracování transakcí, protože i s tím lze snadno vyrobit nekonzistentní data, pokud se to nepoužívá správně.

Jedná se právě o běžný způsob jak navrhnout paralelní aplikace - příjmout více požadavků, ale vykonat je ve frontě jeden po druhém

Běžný způsob možná pro aplikace, kde vůbec nejde o výkon, a když se náhodou sejdou dva uživatelé, tak si holt jeden počká.

kdy jednotlivé transakce nejsou na sobě závislé - výsledek není závislý na pořadí vykonání jednotlivých transakcí

Stačí, že někde máte čítač, který se s každou transakcí zvedne o jedničku –  a na pořadí transakcí hned záleží. Nebo jedna transakce jeden záznam aktualizuje a druhá ten samý maže – opět záleží na pořadí, pokud se provedou v opačném pořadí, než jsme uvedl, druhá transakce skončí chybou.

3914

Software / Re:Náhrada FTP

« kdy: 18. 06. 2017, 14:54:33 »

U obou těhle řešení je problém s virtálními usery i adresáři

Za prvé to nijak nesouvisí s protokolem, virtuální uživatelé i adresáře jsou věcí implementace. Za druhé to, že vy s tím máte nějaký nespecifikovaný problém, neznamená, že je s tím problém obecně – spousta uživatelů s tím žádné problémy nemá.

navíc rozchodit to (na rozdíl od FTP) není úplně jednoduché

Rozchodit co? SFTP server jsem nerozcházel, funguje mi automaticky jenom tím, že jsem zprovoznil SSH server.

Navíc se to dělí o číslo portu s nadřazeným protokolem (porty 22 a 80).

Použijí se porty, jaké nakonfigurujete.

Já žádnou plnohodnotnou náhradu (prostě protokol, určený primárně k obousměrnému přenosu souborů v internetu) nenašel.

SFTP, HTTP(S), HTTP(S)+WebDAV, rsync, OpenStack Shared File Systems API, OpenStack Object Storage API, různá API  cloudových úložišť (DropBox, OneDrive, Google Drive)…

Nenapsal jste, jaký problém řešíte, takže vám s ním těžko někdo poradí…

3915

Software / Re:Jak funguje licencování Jboss vs Wildfly

« kdy: 17. 06. 2017, 22:11:10 »

JBoss je zdarma protože je to open source projekt, který je pod licencí GNU GPL. Tedy ho lze volně stáhnout a používat v produkčním prostředí.

Tohle není pravda. GPL znamená jenom to, že ten, kdo šíří aplikaci na základě GPL, musí dát uživatelům k dispozici i zdrojáky. Navíc JBoss EAP for Development Use není k dispozici pod GPL, ale za podmínek RedHat Developer Program. Pod GPL je licencován Wildfly.