Příspěvky

4531

Software / Re:Potíže s Javou při použití certifikátu pro vstup na web

« kdy: 08. 04. 2016, 21:56:52 »

Tak ja by som toto spravanie sa aplikacie zrovna za "prasarnu" alebo "humus" neoznacoval.

Zjevně máte velmi posunutý práh bolesti.

Podla dostupnych informacii z logu sa to snazi doinstalovat JCE kniznicu, teda java kryptograficke rozsirenie.

Ne, podle dostupných informací z logu se to snaží doinstalovat JCE, ale vedle ní také další knihovny.

Třeba KeyStore Explorer ke svému běhu také potřebuje JCE, ale řeší to tak, že uživateli v prohlížeči otevře příslušnou stránku ke stažení a instruuje uživatele, co má s knihovnou udělat. Což je postup, který vede k cíli, protože to udělá uživatel sám, pokud může získat příslušná oprávnění, nebo má přesný popis, co má požadovat po správci.

Navíc tenhle způsob pokoutné distribuce a instalace je nejspíš nelegální – před stažením JCE z webu musíte odsouhlasit nějaké podmínky, v README v distribuovaném souboru jsou napsané další podmínky, na to celé ta aplikace kašle.

Postupoval by som presne ako technomaniak - stiahol tieto kniznice manualne a nakopiroval ich do java adresarovej struktury.

Při vašem snížené prahu bolesti vás asi nenapadlo, že to vůbec nemusí stačit, protože té aplikaci může být úplně jedno, že tam ty knihovny už jsou, a může se pokoušet je tam nainstalovat znova.

Navíc ta aplikace se tam pokouší nainstalovat různé knihovny, např. kryptografickou knihovnu IAIK. Tu tam nainstaluje v nějaké své verzi, jiná aplikace bude chtít použít IAIK ve své verzi, jenže IAIK v bootclasspath dostane přednost – a ta aplikace nebude fungovat.

Nebo-li pokud si chce uživatel úplně rozbít JRE, aby mu přestalo fungovat co nejvíc Java aplikací, doporučuju ten postup s kopírováním knihoven do systémového adresáře.

Podla mojich znalosti java dovoli nacitat niektore kniznice len z $JAVA_HOME adresara (a jeho podadresarov).

To máte špatné znalosti. $JAVA_HOME je systémová proměnná prostředí, která podle konvence ukazuje JRE nebo JDK. Ale tu konvenci používají některé Java programy, samotné JRE od Oracle tuhle proměnnou vůbec nepotřebuje.

Knihovny umístěné v adresářích JRE se automaticky přidávají na BOOTCLASSPATH a mají přednost před knihovnami ve standardní CLASSPATH. Ale i BOOTCLASSPATH je možné při startu aplikace změnit.

JCE kniznice sa zvycajne instaluju do "Java Optional Packages" adresara - $JAVA_HOME/jre/lib/ext.

Ne, instalují se do JRE do adresáře lib/security. Což zjistí každý, kdo si JCE normálně stáhne a přečte si soubor README.txt uvnitř toho staženého zipu. Pokud někomu tu knihovnu pokoutně podstrčí do systému nějaká aplikace, tak se tohle samozřejmě nedozví.

4532

Hardware / Re:Oddíl jako /dev/sda namísto /dev/sda1

« kdy: 08. 04. 2016, 21:27:19 »

/dev/sda značí disk jako takový, /dev/sda1 je první oddíl na daném disku, pokud je disk rozdělen na oddíly. Ano, zapisujete přímo na disk, ne do oddílu na disku. V unixech to ničemu nevadí, tam si můžete vytvořit souborový systém na jakémkoli blokovém zařízení, třeba v souboru na disku. Takže souborový systém přímo na disku zvládne stejně dobře, jako souborový systém v oddílu. Některé jiné systémy by s tím mohly mít problém, protože očekávají, že disk bude obsahovat oddíly – ale takové systémy nebudou rozumět ani Ext4, takže je to jedno. TRIM bude fungovat správně, dokonce vám odpadá problém s tím, jak umístit začátek oddílu, aby sektory souborového systému lícovaly se sektory disku.

Nevýhody mne napadají dvě – nemůžete dodatečně zmenšit souborový systém a vytvořit na disku další oddíl, a nemůžete ponechat na disku volné místo mimo oddíly a tím disku ponechat větší prostor pro wear leveling (předpokládám, že jste využil pro souborový systém celou kapacitu disku). Výhodou je, že jste ušetřil pár bajtů zbytečné tabulky rozdělení disku 

4533

Server / Re:DNS s konfigurovatelným blacklistem

« kdy: 08. 04. 2016, 15:12:52 »

Jaky DNS server by jste na tuto extremi konfiguraci dlasiho DNS serveru doporucily? Zatim uvazujem nad Knot resolverem a klasickym bind.

Co je na tom extrémního? A proč chcete používat dva DNS servery? Použijte libovolný DNS resolver – Knot DNS Resolver, Unbound, Dnsmasq…

Navrzeneho reseni je i z pohledu edukace uzivatelu korektni - chyba certifikatu proste tam nelez at jiz je duvod jakkykoliv. Muzeme rici uzivatelum aby neignorovali chybu certifikatu a ze stranky s chybou certifikatu odesly.  Ale at nase doporuceni budou ignorovat ci nikoliv na stranku na ktereou by se z objektivniho duvodu nemeli dostat se nedostanou, coz je cilem. Proste chyba certifikatu je spatne at je duvod jakkykoliv.

To ale vycházíte z mylného předpokladu, že uživatel nemá co dělat, a tak jen tak zadává do prohlížeče adresy – a když se na nějakou nedostane, zkusí jinou. Jenže ve skutečnosti uživatel jde na tu stránku s nějakým cílem, který odejitím kvůli chybnému certifikátu není splněn. Takže uživatel se bude pokoušet tam stejně dostat, případně bude zjišťovat, kde je problém.

4534

Server / Re:DNS s konfigurovatelným blacklistem

« kdy: 08. 04. 2016, 12:22:29 »

Uzivatel se na zakazany URL nedostane

Ano, to je jediné, na čem se shodneme.

potvrdi chybu certifikatu v pripade HTTPS -coz by samozrejme ale nemel

Což by neměl, ale proč by ho to IT oddělení nemohlo naučit, že. Správně by uživatel neměl v takovém případě odkliknout certifikát, ale měl by místo toho kontaktovat IT oddělení s tím, že došlo k bezpečnostnímu incidentu a někdo se pokusil zaútočit na jeho prohlížeč. Jestli to chcete neustále řešit…

Navíc v případě, že doména používá DNSSEC, uživatel nezíská vůbec žádnou DNS odpověď.

Ale oproti ostanim resenim kontroly HTTPS na aplikacni urovni jez musi  de/kryptovat mi toto reseni prijde zlate.

Pokud je vaším cílem to, aby uživatelé kašlali na bezpečnost, pak jistě. V opačném případě je problém už v tom „řešení kontroly HTTPS“, protože to žádné řešení není.

4535

Server / Re:DNS s konfigurovatelným blacklistem

« kdy: 08. 04. 2016, 09:42:43 »

Mám zkušenost, že občas nějaký web používá HTTPS. Třeba Google, Seznam, banky – a těch webů je čím dál víc, a teď zrovna jsme v období, kdy se na HTTPS masivně přechází (tlačí na to autoři prohlížečů, Let's Encrypt umožňuje získat certifikát zdarma). Na jakémkoli webu s HTTPS ten váš únos spojení přes HTTPS nebude fungovat, protože místo informace o zákazu zobrazí prohlížeč chybu certifikátu.

Takže doporučuji opustit tohle neperspektivní řešení, dokud máte čas a webů s malwarem na HTTPS ještě není mnoho.

4536

Server / Re:PHP - výstup do prohlížeče v kombinaci se sleep()

« kdy: 06. 04. 2016, 21:14:55 »

Možná jde i v PHP udělat nějaké zpracování na pozadí a sdílení paměti. A nebo ten váš způsob – postupné odesílání dat – použijte v tom AJAXu. Pro načítání dat AJAXem to bude fungovat – používalo se to jako server push technologie (long polling) před vznikem WebSockets.

4537

Server / Re:PHP - výstup do prohlížeče v kombinaci se sleep()

« kdy: 06. 04. 2016, 20:22:41 »

Použijte AJAX – odešlete celou stránku, a z ní se pak budete opakovaně dotazovat serveru. Případně, pokud nechcete používat JavaScript, použijte automatickou obnovu stránky (meta refresh).

Nejde spoléhat na to, že prohlížeč bude postupně vykreslovat stránku tak, jak dostává její zdroják. Jak vidíte, nefunguje to.

4538

Server / Re:httpd pid se meni

« kdy: 06. 04. 2016, 07:21:58 »

po startu vidim pomoci netstatu, ze proces co posloucha na portu 443 ma pid treba 1000

Předpokládám, že používáte netstat -l, tedy skutečně naslouchající proces?

httpd proces se nerestartoval

To zjistíte jak, že se nerestartoval? Udělejte si výpis procesů v prvním případě a za tu hodinu – za nejpravděpodobnější považuju, že v prvním případě tam bude jenom ten první proces a ve druhém jenom ten druhý. Podle času modifikace adresáře v /proc podle mne také zjistíte čas spuštění příslušného procesu. Myslím, že zjistíte, že se ten proces ve skutečnosti restartuje.

4539

Software / Re:Potíže s Javou při použití certifikátu pro vstup na web

« kdy: 27. 03. 2016, 08:01:33 »

Pod rootem jsem pouštěl pouze tuto stránku.

Jenom celou stránku a celou tu šílenou aplikaci, která vyžaduje plný přístup k zápisu kamkoli na váš disk. Autor té aplikace je buď neuvěřitelně drzý, a řekl si, že když ke škodění potřebuje rootovská práva, tak si o ně prostě řekne. A nebo je neuvěřitelně neschopný, pak bych se nebál úmyslného útoku, ale toho, že  ta aplikace bude pěkně děravá.

Proč k podpisu certifikátem potřebují Javu nevím, podle mě jde možná o anachronismus z pradávných let, na portálu VZP vše běží přes prohlížeč a bez problémů.

Vy jste předtím psal o přihlášení. K tomu Java potřeba není. Teď píšete o elektronickém podpisu, ten naopak v současné době není možné bezpečně udělat jen v prohlížeči, Java je pak nejlepší volba (podpis v prohlížeči jde udělat jedině s privátním klíčem v souboru, což má k bezpečnosti daleko).

Možnost, že ovlivním portál ZP  k nějaké změně je asi nulová, budu se s tím muset smířit

Pokud se s tím smíříte, je ta možnost opravdu nulová. Ono je klidně možné, že programátoři toho portálu se už mezitím naučili, jak se distribuují Java aplikace, ale když to chtějí změnit, zeptá se manažer nebo zadavatel – stěžoval si někdo? Nestěžoval, takže není důvod to měnit.

kolegové s Windows budou dál používat ActiveX řešení.

To ActiveX řešení předpokládám funguje jenom v Internet Exploreru.

Ty informace podpoře portalzp.cz předám, ale je to jako byste chtěl takové změny po bance nebo státní správě.

To já si představit dokážu. Programátoři takových aplikací si dokážou vymyslet takové opravy a vylepšení, že by vás jako klienta nikdy nenapadly. Akorát to nebudou dělat ve svém volném čase a klienti jsou spokojeni se současným stavem.

4540

Software / Re:Potíže s Javou při použití certifikátu pro vstup na web

« kdy: 26. 03. 2016, 19:20:40 »

Tohle nesouvisí s Linuxem. Úplně stejně dopadnete ve Windows, pokud budete přihlášen jako běžný uživatel. To, že bude aplikace z webu zapisovat do systémových adresářů opravdu není dobrý nápad. Navíc je to úplně zbytečné, ta aplikace vůbec nepotřebuje mít ty knihovny v systémovém adresáři Javy, může je mít jako aplikační knihovny jako každá jiná aplikace. Opravdu by mne zajímalo, jak může takovouhle aplikaci vytvořit někdo, kdo vůbec neví, jak se Java aplikace distribuují.

Navíc by mne zajímalo, k čemu tu aplikaci tedy vlastně potřebují, protože přihlášení privátním klíčem je normální součástí HTTPS a umí to každý webový prohlížeč.

Ale jestli máte odvahu spouštět pod rootem webový prohlížeč a v něm aplikaci, která může dělat v systému cokoli, klidně to udělejte – mně je to jedno, můj počítač to není.

vyřešení tohoto problému znamená možnost mít jako pracovní os linux pro řadu ambulancí

Tento problém ale nemůže vyřešit nikdo jiný, než autor té aplikace. Stačí, aby se naučil, jak se distribuují javovské aplikace, a aplikaci znovu zabalil. Navíc jak už jsem psal, s Linuxem to nijak nesouvisí.

4541

Software / Re:Potíže s Javou při použití certifikátu pro vstup na web

« kdy: 26. 03. 2016, 11:11:50 »

To se vám ta aplikace pokouší modifikovat systémovou Javu. To je teda megaprasárna a je správně, že na to při přihlášení jako běžný uživatel nemáte oprávnění. Jak tam píšou, kontaktujte linku podpory, pošlete jim ten log, a řekněte jim, že administrátorskými právy se přihlašovat nebudete, protože k tomu není žádný důvod (a ani ta administrátorská práva nemusíte mít).

4542

Software / Re:Potíže s Javou při použití certifikátu pro vstup na web

« kdy: 25. 03. 2016, 13:04:23 »

Určitě bych začal tím, že si nainstalujete aktuální produkční verzi Javy, tedy Javu 8 (konkrétně od Oracle Java SE 8u77). Java 9 je teprve ve vývoji, takže bych se vůbec nedivil, pokud s ní nějaká aplikace nebude fungovat.

4543

Server / Re:Zvýšení dostupnosti u VPS

« kdy: 24. 03. 2016, 09:51:04 »

postavit to cele na DNS s nizkym TTL je skutecna a plnohodnotna kravina s prihlednutim k tomu jak funguje cachovani a propagace DNS zaznamu mezi servery

I kešující DNS server se má řídit TTL záznamů. Server může mít nějaký limit, že příliš nízké TTL bude ignorovat – ale ten limit bude u rozumně nakonfigurovaných serverů maximálně v řádu jednotek minut.

Nízké TTL pro DNS záznamy používá třeba Google, Amazon, z českých Seznam a mnoho dalších poskytovatelů služeb. Nezdá se, že by jim to nefungovalo.

pro zacatek bych zacal googlit ktery provider nabizi failover IP (ovh, superhosting, master atd.)

SuperHosting těžko nabídne failover IP přes různé lokality, když má jedno datacentrum. U OVH jsem nenašel, zda poskytuje IP failover přes různé lokality. Každopádně IP failover u jednoho poskytovatele řeší problém výpadku jednoho VPS serveru, ale neřeší to problém při výpadku síťové infrastruktury ISP (na druhou stranu, „levná řešení“ asi neznamená, že by bylo potřeba být chráněn i proti výpadkům infrastruktury ISP).

4544

Hardware / Re:Otázky ohľadne data recovery

« kdy: 23. 03. 2016, 16:08:05 »

Použití mini PC může mít na výkon podstatný vliv, protože ne všechna podporují SATA plnou rychlostí, často je SATA implementováno přes USB převodník (takže se dostanete v lepším případě zpět na rychlost USB 2.0). SATA dosahuje také různých rychlostí, záleží na verzi.

Maximální teoretická rychlost USB 2.0 je 280 Mbit/s, navíc USB má velkou režii. SATA 3 má maximální teoretickou propustnost 6 Gb/s, takže ten rozdíl je řádový (samozřejmě na to musíte mít řadič i disk). Ale i SATA 1 má 1,5 Gbit/s, což je pořád alespoň o řád víc, než kolik vymáčknete z USB.

Pořád je to ale kopírování v řádu hodin. Pokud 2 TB disk kopírujete 2 měsíce, není rozdíl v tom, zda použijete USB nebo SATA, ale je to způsobené tím, že se disk pokouší nečitelná místa přečíst opakovaně a nečitelného je na tom disku asi hodně.

4545

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 23. 03. 2016, 08:24:29 »

možnost nepřepínání se z funkcionálního světa do javascriptu.

Tomuhle nerozumím. Vždyť JavaScript je také funkcionální. Chcete jazyk, který bude jen funkcionální a nebude podporovat jiná paradigmata?