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 ... 240 241 [242] 243 244 ... 375
3616
Píšete, že licence byla zakoupená s počítačem A, takže předpokládám, že je to OEM licence vázaná na daný počítač. Na počítač B ji tedy přenést nelze.

3617
Software / Re:Image diff tool
« kdy: 06. 01. 2018, 13:28:56 »
diff-pdf vizuálně porovnává PDF. Stejný princip můžete použít i pro samostatné obrázky. Nevím o nástroji, kde už by to bylo naimplementováno, ale třeba něco najdete. Případně by to možná mohlo jít naskriptovat pomocí ImageMagick nebo v Gimpu. A nebo to samozřejmě můžete vzít hrubou silou, ty obrázky převést na PDF a ta porovnat tím diff-pdf.

3618
Sítě / Re:DNS a ISP
« kdy: 31. 12. 2017, 15:04:20 »
K tomu, co napsal Franta, doplním ještě jeden rozdíl. Velcí poskytovatelé služeb, kteří mají servery na více místech, používají DNS pro směrování na nejbližší server. Když to zjednoduším, když dotaz na jejich DNS server přijde z Evropy, v odpovědi pošlou IP adresu evropského serveru, když DNS dotaz přijde z USA, pošlou v odpovědi IP adresu serveru v Americe. Pokud byste byl u většího ISP, může se stát, že s nějakým poskytovatelem obsahu má speciální peering, a na dotazy z DNS vašeho ISP bude odpovídat příslušnou IP adresou. Když ale použijete DNS server CZ.NIC, bude to bráno jako dotaz „odněkud z ČR“ a třeba vás to pošle na server, který z hlediska infrastruktury vašeho ISP není tak výhodný (bude třeba dál, takže budete mít větší latenci).

A ještě jedna věc – pokud ISP poskytuje vlastní DNS servery, měly by ty servery překládat samy od kořenové zóny, ne být napojené na servery NIC.CZ nebo Googlu. Tyhle otevřené servery jsou pokud vím určené pro koncové uživatele, a nedává moc smysl, aby se jich dotazovaly servery ISP – nepřináší to nikomu žádné výhody, spíš jen nevýhody.

3619
Server / Re:Anonymní nahrávání souborů na webu
« kdy: 30. 12. 2017, 12:19:17 »
Pokud to chcete na vlastním serveru, zprovozněte si tam FTP nebo WebDAV. Pokud to chcete jako službu, umí to různá cloudová úložiště, např. Dropbox.

3620
Software / Re:Univerzální šifrované úložiště
« kdy: 28. 12. 2017, 20:10:01 »
VeraCrypt a soubor s šifrovaným oddílem sdílet – přes vlastní server, přes Dropbox, jak chcete.

3621
Vývoj / Re:Oprava css layoutu
« kdy: 28. 12. 2017, 19:04:28 »
Rada nepoužívat na to tabulku byla správná. Na tohle se ideálně hodí flexbox.

Kód: [Vybrat]
.col-container {
    display: flex;
    width: 100%;
}
.col {
    flex-grow: 1;
    margin: 0 10px;
    padding: 16px;
}

3622
Server / Re:telnet
« kdy: 27. 12. 2017, 16:03:45 »
To záleží na konkrétní implementaci serveru, který používáte. Nevidím ale jediný důvod, používat telnet – spojení není šifrované, takže je snadné ho odposlouchávat. Použijte raději SSH, na Linuxu konkrétně OpenSSH. Spojení je šifrované, je možné se bezpečně autentizovat – a přihlášení můžete pomocí AllowGroups omezit pouze na členy konkrétních skupin, pomocí AllowUsers můžete vyjmenovat konkrétní uživatele (případně pomocí DenyGroups nebo DenyUsers můžete naopak přihlášení některým uživatelům/skupinám zakázat).

Střílením náhodných dotazů na detaily se ale nic nenaučíte a k žádnému výsledku nedospějete. Bylo by lepší, kdybyste popsal, jaký problém vlastně řešíte. A nebo, pokud si jen tak hrajete, raději si přečtěte nějakou knížku nebo manuál, kde se dozvíte věci v souvislostech.

3623
Windows a jiné systémy / Re:Nastavení práv službě
« kdy: 26. 12. 2017, 08:48:47 »
V Linuxu se nepřidělují práva programům, ale uživatelům a skupinám. Ta služba běží pod nějakým uživatelem, tedy nastavíte práva tomu uživateli.

3624
Seznam uživatelů v linuxu najdete v souboru /etc/passwd, seznam skupin v /etc/groups. Linux na úrovni systému nerozlišuje systémové a nesystémové uživatele – pouze je zvykem systémovým uživatelům dávat UID menší než 1000 a obyčejným uživatelům UID od tisíce výš.

Práva na soubory se v Linuxu nastavují pomocí příkazu chmod, vypsat je můžete například příkazem ls -l.

Jediný speciální uživatel v Linuxu je root (rozhodující je UID=0) – ten má práva ke všemu.

3625
Jo, za predpokladu, ze v autentikaci SSH neni nejaka dosud neznama chyba.
Což ale platí i o používání su nebo sudo. A obecně zabezpečit počítač proti lokálnímu útočníkovi je řádově složitější, než zabezpečit ho proti vzdálenému útočníkovi.

Krome toho neni tak spatne, kdyz se kazdy prihlasi na svuj neprivilegovany ucet a pak da su, aby v logu bylo videt, kdo tam v kterou dobu lezl. Kdyz se neco posere a nekdo pak jede pres pul zemekoule zmacknout tlacitko reset, tak se aspon vi, koho za to nakopat.
Stejně tak je v logu vidět, kterým klíčem se někdo přihlásil. Použití su nepřináší v tomhle případě žádnou přidanou hodnotu.

Ano, pokud pouzijete zminene klice a ne uzivatele s heslem.
To je podle mne základní bezpečnostní požadavek. Nechápu, že někdo komplikuje přihlašování su a řeší evidenci konkrétního přihlášeného uživatele, a přitom nechá uživatele přihlašovat se heslem.

Navic musite klice dukladne evidovat
Stejně důkladně, jako evidujete přihlašovací jména.

3626
Jo, pokud chcete mit v SSH povoleno prihlasovani na roota, coz je ponekud v rozporu z predchozimi doporucenimi pouzit neprivilegovaneho uzivatele.
Ano, vždyť jsem to také psal – lepší je údaje sbírat lokálně (to může dělat root, když je potřeba) a pak je pomocí neprivilegovaného účtu poslat na sběrný server. Tohle byla jen poznámka, že pokud to chce dělat tím svým způsobem, nic nebrání tomu přihlašovat se na roota s klíčem (naopak bych se na roota nepřihlašoval heslem). Navíc je možné s konkrétním klíčem svázat konkrétní příkaz, takže se dá docela dobře zabezpečit, co může vlastník toho klíče dělat (je to takové sudo, které má mnohem méně nečekaných vedlejších efektů).

Mozna, ze kdyz to beha v LAN, tak by se to dalo skousnout, ale pres Internet bych to nechtel.
Na přihlašování pod rootem není nic divného nebo nebezpečného. Nebezpečné je přihlašování slabým heslem, ale na to existuje jednoduchý lék – přihlašování heslem úplně zakázat.

3627
K řešení ssh s klíčem (neprivilegovaný uživatel) - některé příkazy potřebují práva roota.
Klíčem se můžete přihlásit i na roota. A jak už pal Franta, ke konkrétnímu klíči můžete nastavit příkaz, který se po přihlášení tím klíčem spustí. Takže můžete nastavit, aby se s příslušným klíčem spustil jenom skript, který posbírá potřebná data, a nic jiného s tím klíčem nepůjde udělat. Bezpečnější by ale bylo dělat to opačně, tj. na počítači posbírat data a pak je odeslat někam ven.

3628
Odkladiště / Re:Je hashovaný údaj osobný údaj?
« kdy: 19. 12. 2017, 16:51:28 »
1. Ověřit formát - protože ten nebyl až tak pevný, délka se mohla lišit

Obecně je to důsledek legislativy, kdy platné je rodné číslo zapsané v rodném listě. Pokud někdo udělal chybu, například vynechal číslici, spletl si číslice, ze seznamu volných rodných čísel vybral špatné, neoznačil správně použité rodné číslo atd., tak sice to rodné číslo bylo špatně, ale platilo. Co bylo na papíře, to bylo platné. Žádná centrální evidence neexistovala, takže nikdo nic neověřoval. Navíc i když se našla chyba, tak se to obvykle nechávalo tak.
Zas až takový guláš v tom snad nebyl. Přehození číslic v části za lomítkem, špatná kontrolní číslice, duplicita, to všechno může být. Ale datum narození v rodném čísle a délka rodného čísla (9 číslic do roku 1953, 10 číslic od roku 1954) podle mne musí platit vždy.

3629
Vývoj / Re:Java: String constants a velikost bajtkódu
« kdy: 18. 12. 2017, 21:35:53 »
Spíš přemístit potřebnou funkcionalitu do třídy k tomu řetězci a ponechat ho jako privátní.
Co když je tím řetězcem třeba UTF-8 a označuje to kódování dat na vstupu nebo výstupu? Tam, kde to jde, používám Charset (ale to je jen konstanta jiného typu), ale spousta metod má na vstupu jako parametr pro kódování jenom String.

Taková "co když" bývají docela zábavná. Use Case neznáme, tedy ani nevíme, zda nějaké "co když" nastane.
Nechtěl jsem prodlužovat komentář spoustou příkladů, předpokládal jsem, že každého napadne nějaký z jeho praxe. Tedy několik use case:

  • Potřebuji zapsat JSON do souboru, zapisuji přes Writer vytvořený pomocí java.nio.file.Files.newBufferedWriter() (tohle je zrovna ta varianta s Charsetem)
  • V servletu nastavuji, že výstup bude text/html v UTF-8, volám HttpServletResponse.setCharacterEncoding()
  • Potřebuji načíst text přes HTTP, použiju Apache HttpComponents a odpověď serveru převádím na String pomocí org.apache.http.util.EntityUtils.toString()
  • Potřebuji elektronicky podepsat uživatelem zadaný text, na Stringu tedy zavolám getBytes(), abych mohl spočítat hash textu.

Stačí takhle?

3630
Vývoj / Re:Java: String constants a velikost bajtkódu
« kdy: 18. 12. 2017, 20:20:11 »
Spíš přemístit potřebnou funkcionalitu do třídy k tomu řetězci a ponechat ho jako privátní.
Co když je tím řetězcem třeba UTF-8 a označuje to kódování dat na vstupu nebo výstupu? Tam, kde to jde, používám Charset (ale to je jen konstanta jiného typu), ale spousta metod má na vstupu jako parametr pro kódování jenom String.

Stran: 1 ... 240 241 [242] 243 244 ... 375