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 ... 348 349 [350] 351 352 ... 375
5236
Server / Re:sftp skopirovanie adresara v ramci serveru
« kdy: 24. 05. 2014, 16:39:43 »
Pokud máte na serveru povolené sftp, možná tam máte i scp - a scp protokol příkaz cp umí. Případně vyzkoušejte, zda v sftp nemáte povolené spouštění příkazu cp přes shell.

5237
Sítě / Re:firemní firewall
« kdy: 20. 05. 2014, 14:16:01 »
V Linuxu je firewall přímo součástí jádra a jmenuje se netfilter. K jeho ovládání slouží sada nástrojů iptables, což jsou konzolové nástroje. To je vše, co je k provozování firewallu na linuxu nutné. Pak existují různé nadstavby, často s grafickým „klikátkem“, pomocí kterých můžete pravidla firewallu spravovat – tyto nadstavby pak interně zase volají iptables. Abyste mohl firewall nakonfigurovat, potřebujete vědět, jak funguje – jaká pravidla se kdy na procházející paket aplikují. Když si tohle nastudujete, můžete se pak sám rozhodnout, zda budete používat přímo iptables, nebo co byste vyžadoval od nějakého nástroje nad tím.

5238
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 17:59:50 »
Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat.
Tazko niekoho donutite kontrolovat nieco, co sa vyskytuje u niecoho ako 1 z 10k pripadov alebo menej. To z principu nejde - aj ked na uradnicku budete najskor davat pozor, casom si vsimne, ze je to "vzdy spravne" a jednoducho to bude v hlave ignorovat.
Jste si jist, že váš komentář nějak souvisí s tím, na co reagujete?

To u vas normalne funguje tak, ze ked uradnicke nieco nejde, tak si nieco vymysli, aby to nejak preslo?
Ne. Když něco nejde (třeba zadat žádost o důchod z důvodu duplicity rodného čísla), úřednice oznámí možnou chybu v systému, problém se analyzuje, zjistí se, že jde skutečně chyba v zadání, vypíše se výběrové řízení na úpravu software (nezapomeňte, že jde o změnu zadání, ne opravu chyby), no, a až tohle celé proběhne, může si dotyčný přijít požádat o důchod znovu.

Ale myslím, že ke zjištění, že se ptáte na pěkný nesmysl, se stačilo trochu zamyslet.

5239
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 17:35:44 »
V takových případech ale zase není nutné tam ten údaj vůbec mít.
To pak nevím, jak budete v zaměstnání, ve škole nebo na úřadě osoby identifikovat. Rodná čísla, jména a příjmení a adresy trvalého bydliště odstraníte, a jak pak poznáte, komu máte třeba vydat diplom nebo vyplatit důchod?

5240
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 17:14:39 »
To, že něco, co bylo původně navrženo jako unikátní nakonec tak moc unikátní není a ještě k tomu to nikdo nechce řešit
Tady se nebavíme o tom, jak něco bylo navrženo, ale jaký je o tom předpoklad. Někdo předpokládá, že rodná čísla jsou unikátní (v zákoně je napsáno, že totéž rodné číslo nesmí být přiděleno více osobám), ale pak se zjistí, že dříve nějaká duplicitní rodná čísla přidělena byla. A že to nikdo nechce řešit? Má škola nebo zaměstnavatel prohlásit: "Vážený pane, máte duplicitní rodné číslo, náš informační systém ho nedovolí zadat, tak si laskavě nechtě přidělit nové rodné číslo, a pak vás možná vezmeme?" To, že jsou duplicity  někde, kde by být neměly, je problém té primární evidence, která ty identifikátory přiděluje. Nikdo jiný to vyřešit nemůže, ostatní se mohou jen přizpůsobit a počítat s tím, že to s tou unikátností není až tak slavné.

je podle mě tak velká změna zadání, že to vyžaduje v podstatě nový návrh. Protože ona změna unikátnosti má podstatný vliv na další logiku aplikace.
Na další logiku aplikace to nemusí mít vůbec žádný vliv. Třeba pokud pro evidenci osob používám umělý primární klíč a rodné číslo používám jenom jako jeden z evidenčních údajů, nemá změna unikátnosti rodného čísla na logiku aplikace žádný vliv. Dříve uživatel vyhledal osobu podle příjmení nebo rodného čísla a podle dalších údajů ověřil, že jde skutečně o tu správnou osobu (případně podle nich vybral tu správnou), nově bude postupovat úplně stejně.

5241
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 16:30:52 »
Rodné číslo také má být unikátní. Jak už jsem psal, to, že nějaký identifikátor není primárním klíčem, ještě neznamená, že se unikátnost nemůže kontrolovat (s varováním) nebo vynucovat. Systém může uživatele varovat, že zadává duplicitní VIN, může vyžadovat schválení duplicitního VINu od dalšího uživatele nebo od vedoucího. Dokonce může mít i kontrolu na unikátnost VIN v databázi, ale když se použije umělý primární klíč, pořád je možnost aplikaci jednoduše upravit, až se přijde na to, že v praxi VIN unikátní není. Je mnohem jednoduší zrušit unikátní index a doplnit varování do aplikace, než ve všech odkazujících tabulkách měnit klíč.

5242
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 15:34:39 »
Ano, praktická zkušenost to bohužel je. A na základě této praktické zkušenosti potom vznikají situace, jako že je třeba vymáhána pohledávka pro zcela jiném člověku podobného jména nebo bohužel neunikátního rč a nikdo se nenamáhá to řešit. Do systému to naťukat lze, počítač řekl, že dlužíte, tak plaťte.

Pokud má někdo za úkol napsat systém pro evidenci vodizel, tak VIN je pro měj dostatečně unikátní už z definice na to, aby z něj mohl být i PK. Protože v běžném režimu se nemůže stát, že dvě různá vozidla mají stejný VIN. Pokud se tak stane, nelze nad tím mávnout rukou, naopak se to musí řešit mimořádně. Systém, který umožní zapsat dvě vozidla se stejným VIN jaksi nikoho nenutí to řešit a v praxi to dopadne nejjednodušší možnou cestou, že to tam dotyčný operátor prostě nechá.
To, že nějaký údaj není v PK, vůbec neznamená, že se nemůže kontrolovat unikátnost takového údaje. Naopak ten váš přístup znamená, že se pohledávka bude vymáhat po někom úplně jiném, nebo že se na tu duplicitu VIN nepřijde. Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat. A pro to auto si vymyslí jiný VIN, a ten do databáze zadá. Protože je to pořád menší otrava, než to auto neevidovat vůbec.

Všimněte si, že to vyžadování unikátnosti tam, kde v reálném světě identifikátor unikátní není a obsluha programu ten identifikátor nemůže nijak ovlivnit, tu chybu nikdy neopraví, naopak to připraví půdu pro vznik dalších chyb.

5243
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 14:33:22 »
Ale všechno má svoje limity, a je dost jiné než klasické OOP programování (případně ještě říznuté ORM).
Ono se zas až tak moc objektově neprogramuje, spíš je to programování s objekty. Zvlášť tam, kde se používá ORM - to je klasické procedurální programování, kde máte datové struktury (to jsou ty ORM "objekty", kde se akorát s daty z venku nepracuje přímo, ale pomocí getterů/setterů nebo properties) a vedle toho kód, který se těmi strukturami něco provádí (dnes se mu většinou říká služby).

5244
Odkladiště / Re:Co je to cloud a k čemu to je?
« kdy: 17. 05. 2014, 08:44:34 »
důvody PROČ vyvíjet cloudové aplikace atd... ?

Já osobně v tom nevidím zatím důvod proč bych měl sednout na zadek a začít vyvíjet aplikace určené pro nasazení do cloudu... A nebo jsem fakt tak už blbý ? :)
Mirek Prýmek dobře odpověděl na to, co je to cloud, já ještě doplním odpověď na tuhle část dotazu.

A jak už to tak bývá, ta otázka "proč začít vyvíjet cloudové aplikace" je špatná :-) Neřeknete si, že teď budete vyvíjet nějakou cloudovou aplikaci, a teprve pak nezačnete vymýšlet, co to vlastně bude. Je to přesně naopak, chcete udělat nějakou aplikaci, kterou bude najednou používat hodně lidí, bude se používat vzdáleně - takže si dáte nějaké požadavky na technickou infrastrukturu. Že aplikace musí běžet na clusteru serverů, že má být škálovatelná (když přibydou uživatelé, prostě aplikaci jen spustíte na větším množství serverů). A pak si řeknete, že se o tu technickou infrastrukturu vlastně vůbec nechcete starat, že ji nakoupíte jako službu - a to je cloud.

5245
Server / Re:Databazy - programovanie/spravovanie
« kdy: 16. 05. 2014, 16:11:14 »
Ze stejného důvodu jsou vydaná i rodná čísla, která mají chybnou kontrolní číslici.
O tomto neviem - stretli ste sa s tym niekedy?
Jsou to desítky případů, takže narazit na to není zas tak jednoduché.

Mimochodem, málokdo se také podívá na to, jak je rodné číslo v zákoně doopravdy definované. Takže neví, že pokud by byl v daném dni rodných čísel nedostatek, přičte se k měsíci 20 (tj. u žen dohromady 70), čímž vznikne další řada rodných čísel. Takových rodných čísel jsem viděl jednotky a žádné nebylo ověřené, takže nevím, zda už skutečně bylo někdy někomu takové rodné číslo vydané. Ale pokud ano, byl by takový člověk chudák.

5246
Server / Re:Databazy - programovanie/spravovanie
« kdy: 16. 05. 2014, 15:13:25 »
Umely primarny kluc sa dava preto, lebo ostatne "unikatne identifikatory" sa mozu menit, aj ked tak nevyzeraju. Dnes sa da muz preoperovat na zenu, zajtra najdu 2 ludi s rovnakym rovnym cislom, inokedy sa niekto prestahuje do CR a je to. Vdaka tomu mam napriklad ja 2 rodne cisla (ceske a slovenske). A v Cesku ma niekde vedu pod starym slovenskym, lebo mi ho este pridelilo Ceskoslovensko, niekde pod novym ceskym...

V idealnom svete by sa mohlo pouzivat rodne cislo - akurat v praxi to jednoducho nejde.
Navíc rodné číslo není (ani v rámci ČR) ani unikátní identifikátor. Protože se dříve při ručním přidělování rodných čísel občas někdo spletl. Ze stejného důvodu jsou vydaná i rodná čísla, která mají chybnou kontrolní číslici.

PK se za všech okolností používá celé číslo generované místním SQL strojem/clusterem. Opak je projevem nezkušenosti a nevyzrálosti.
Ale ve škole vás budou učit pravý opak.

5247
Hardware / Re:Raspbeery Pi ovládání světel
« kdy: 15. 05. 2014, 12:41:59 »
Pokud má Raspberry vědět o tom, zda je nebo není světlo rozsvícené, je jediná rozumná možnost tím vypínačem na zdi posílat signály do Raspberry a teprve tím to světlo rozsvěcet a zhasínat. Výhodou je, že pak těch vypínačů můžete mít kolik chcete a kde chcete.

5248
Server / Re:Je zobrazování chyb PHP nebezpečné?
« kdy: 15. 05. 2014, 07:04:09 »
Prozrazuje to útočníkovi věci, které by věděl nemusel - třeba název databáze, názvy tabulek, jména funkcí a proměnných, použité knihovny atd. Nic z toho nejde zneužít, pokud v aplikaci (nebo použitých knihovnách apod.) nemáte chybu (např. SQL injection). Ale pokud už v aplikaci takovou chybu mít budete, můžete útočníkovi dost usnadnit práci. Resp. může to znamenat rozdíl mezi cíleným útokem a útokem na první dobrou. Pokud budete mít někde chybu SQL injection a útočník nebude znát jméno tabulky, musí ho buď uhodnout, nebo najít nějakou část aplikace, kde mu přes to SQL injection umožníte názvy tabulek vypsat. Pokud někomu jméno tabulky ukážete v chybovém výpisu, bude chtít vyzkoušet SQL injection a bude sám překvapen, že vám hned prvním pokusem tu tabulku smazal.

Takže není to tak, že byste vypnutím zobrazování chyb vyloženě zabránil nějakému útoku, k tomu je potřeba opravit chyby v aplikaci. Ale je to zbytečné a zbytečně tím útočníkovi napomáháte.

Mně by o něco víc vadilo to, že to vypadá velmi neprofesionálně a uživateli zobrazujete něco, co ho rozhodně nezajímá.

5249
Sítě / Re:Mikrotik WiFi
« kdy: 14. 05. 2014, 11:25:21 »
Umí ten standard n i klient? Pokud umí klient jenom g, je 40 Mbit/s slušná rychlost (maximální rychlost na fyzické vrstvě je 54 Mbit/s). Další věc je, pokud obě strany umí n, zda jsou podmínky pro to, aby se takové spojení navázalo (antény, šířka pásma, rušení).

5250
Server / Re:Rozdělení DB do dvou serverů
« kdy: 12. 05. 2014, 17:57:07 »
Záleží na tom, co myslíte tím „tento problém“. Pokud myslíte ten váš, to už tady napsali jiní – optimalizace aplikace, optimalizace použití databáze, optimalizace konfigurace databáze, optimalizace konfigurace operačního systému, použití jiného databázového systému, použití jiného hardware.

Pokud myslíte, jak se řeší spojení více databází tak, aby bylo možné pracovat s ní jako s jednou logickou databází, např. v Oracle se to řeší pomocí Database Links.

Stran: 1 ... 348 349 [350] 351 352 ... 375