Příspěvky

1351

Sítě / Re:Doporučení VPN služby

« kdy: 29. 05. 2019, 13:13:14 »

PPTP / L2TP / OpenVPN nebrat - vyhnout se jim, co to jde.
(PPTP = nebezpečné, L2TP nepodporuje bezpečně NAT-T, OpenVPN katastrofálně nevýkoná)

Preferovat IKEv2 a SSTP - jednoduché, bezpečné.

1352

Software / Re:Aký software od Microsoftu používate?

« kdy: 29. 05. 2019, 12:33:50 »

Vůbec žádný, nemám Windows a tím pádem ani žádný další produkt od Microsoftu.

A není to, na šéfredaktora, málo, Antone Pavloviči?

1353

Desktop / Re:4K rozlišení a WINE (zvětšení lišt, menu atd ...)

« kdy: 29. 05. 2019, 06:41:44 »

Podle všeho to nemá uspokojivé řešení. Podobný problém se projevuje na MacOS s Retina displeji.
Něco se dá vyřešit zvětšením písem, ale ne každá aplikace na to reaguje korektně.
V případě Winboxu lze maximálně uvažovat o grafickém zvětšení 2x, ale to vypadá to všechno rozmazaně.

1354

Sítě / Re:SQL unikatne ID v select

« kdy: 28. 05. 2019, 22:38:10 »

nikde neni receno ze je to postgresql a v zadnem jinem 'slusnem' sql serveru jsem nevidel tuto syntaxi a urcite neni univerzalni a ani nejrychlejsi

O rychlost nejde, ale na položený dotaz není správná odpověď max() a GROUP BY, protože to dá správné výsledky jen za konkrétní situace - všechny ostatní sloupce vyjma částky budou totožné. Ale tento předpoklad nebyl položen.

V případě MySQL se to musí řešit subselectem, kdy vnitřní select vytáhne příslušný řádek pro danou osobu a vnější select se postará o setřídění výsledků.

1355

Sítě / Re:SQL unikatne ID v select

« kdy: 28. 05. 2019, 20:43:53 »

Bohuzial v laravel ani jedno nesplnilo funkciu 

Pak Váš dotaz není na SQL, ale na něco úplně jiného.

1356

Sítě / Re:SQL unikatne ID v select

« kdy: 28. 05. 2019, 13:00:01 »

treba pouzit group by a funciu MAX().

Daleko správnější by bylo použít "DISTINCT ON (user)" a ORDER BY cash DESC.
Použití agregátu max() by fungovalo pouze ve speciálním případě, kdy by i ostatní sloupce byly stejné. DISTINCT ON () je univerzální řešení.

1357

Server / Re:Pokročilejší automatizovaná záloha

« kdy: 04. 04. 2019, 15:54:00 »

Ahoj, pouzivame klient server reseni, `Bacula` je to zdarma, opensource a super vcetne weboveho klikatka v novejsi verzi. Vyhodou je, ze nebastlis reseni na koleni, spolehlivy system zaloh, ktery je siroce konfigurovatelny, nevyhodou je trochu delsi nastaveni a nez tomu clovek zacne naplno rozumet a orientovat se.

Pokud zmiňujete Baculu, tak pak bych asi doporučil na jejího pokračovatele, Bareos (www.bareos.org).

Bohužel, jak Bacula, tak Bareos trpí spoustou neduhů a jedná se o zastaralý systém. Zejména chybí možnost deduplikace. Systém záloh na "volumes" odpovídá zálohování na pásky. Ten, kdo používá pásky a changer, to ocení; ti, kdo zálohují na disk, pro ně je to jen komplikace.

1358

Odkladiště / Re:OTE chce privátní klíč ke kvalifikovanému certifikátu

« kdy: 03. 04. 2019, 13:53:05 »

Naopak bych to nikde nehlásil. Toto je výhoda pro Vás.
Kdykoliv se Vám něco nebude hodit do krámu, napadnete před soudem systém jako takový a lehce prokážete, že nebyla zajištěna jeho bezpečnost.

1359

Server / Re:Pokročilejší automatizovaná záloha

« kdy: 02. 04. 2019, 17:02:36 »

Velmi příjemně se pracuje s: https://borgbackup.readthedocs.io/en/stable/, ale vyžaduje to nainstalovanou podporu i na straně serveru (tj. nehodí se to pro neznámá úložiště bez další podpory).

Dříve jsem uvažoval i o: https://restic.net/.

Jejich srovnání: https://stickleback.dk/borg-or-restic/.

1360

Software / Re:Nvidia driver vyžaduje Intel driver

« kdy: 17. 03. 2019, 19:59:36 »

spis nestracej cas doporucovanim nekomu W10 kdyz pise ze chce W7, clovek kdo si dava W7 vi proc je chce, nepovazuje je za mrtve... to ze W10 jsou "moderni/zive/aktualni/blabla" je sice hezke, ale kdyz by vyrobce meho jidla zacal prodavat zabalene l3jno taky by me nezajimalo ze je moderni a c00l ;-)

Ze ZAJDANOVA popisu to vypadá, že to není z jeho hlavy, jaký OS tam bude. V tom případě by si měl takové problémy vyžrat ten, kdo takto rozhoduje. Druhou alternativou je koupit model (třeba repasovaný), který má podporu Windows 7. Lámat to mezi sebou je prostě nevděčná práce.

Poměrně solidní alternativou pro případy, kdy je potřeba zachovat kompatibilitu a provozovat starší OS, je spustit současný OS a starší virtualizovat. Je to druhé straghtforward řešení.

Roubovat ovladače bych se snažil až naposledy a po pečlivém zvážení, že neexituje inteligentnější volba.

1361

/dev/null / Re:Riesenie nerealistickych scenarov

« kdy: 17. 03. 2019, 18:11:34 »

Zhodnotíte rizika, náklady a pak stanovíte, co se řeší anebo ne. Testování aplikací typicky řeší právě různé méně pravděpodobné scénáře. Takže ano, do určité míry to řeší doufám každý.

Podle toho. Pokud je sestavený tým, tak se to obvykle řeší. Pokud je to malý projekt o jendom, dvou vývojářích, tak to bývá slabota. Testováním hledají chyby ve vlastní práci (a jejich opravu jim často nikdo nezaplatí), navíc trpí profesionální slepotou.

Prvotní je vždy mít dobře vytrénované vývojáře, kteří dodržují štábní kulturu a chybám předcházejí. Druhotné je mít rozpočet a sílu na testování - běžně testování a opravy chyb ztrojnásobí cenu projektu oproti tomu, když se na to kašle.

1362

/dev/null / Re:Riesenie nerealistickych scenarov

« kdy: 17. 03. 2019, 17:50:32 »

Podle toho, co máte na mysli. Pokud se sestavují testy (scénáře), je nejdůležitejší prací navrhnou je správně, aby se otestovaly hraniční situace. Mnoho situací, které si myslíte, že jsou nerealistické, mohou za rok klidně nastat. Proto se staví "atomová elektrárna", aby systém nespadl např. paralelních přístupech, nebo na přetečení číselných řad atd. atd.

Setkal jsem se s případem shopu, který neměl práci v transakci. Číslo z číselné řady si vzal v jednu chvíli, ale datum zaznamenával až při uložení dokladu. A samozřejmě, v praxi se stalo, že vznikl doklad, který měl číselnou řadu z roku 2017, ale datum z roku 2018.

Pak nad tím systémem byla sada exportů do dalších systémů. A ty exporty programoval pokaždé někdo jiný. Jeden programátor vycházel z číselné řady, druhý z data na dokladu. Exporty se samozřejmě rozjely, protože v jednom exportu doklad byl (byl vzat ještě do roku 2017 podle číselné řad) a v druhém už nebyl, protože ten pracoval podle data.

Tím chci říct, že vymýšlet krajní situace není žádná atomová elektrárna, ale měli bychom se snaži to tak dělat vždy.

1363

Software / Re:Nvidia driver vyžaduje Intel driver

« kdy: 17. 03. 2019, 17:42:14 »

ovladače z webu Aceru na tento konkrétní model jsou jen na Windows 8 a 10,ale mi tam dali 7...chceme je tam.

Tady je podle mě zásadní chyba vůbec ztrácet čas nad nepodporovanou konfigurací. Zejména laciní výrobci laptopů (Acer nevyjímaje) někdy dělají to, že upravují u hardwaru VID a PID, aby na ně nešly instalovat generické ovladače. Někdy mi přišlo, že je to jen primitivní naschválismus, jindy to byla reakce na bugy v hardwaru. Výrobce něco špatně navrhne, pak na to vymyslí přiohnutý ovladač (který chybu narovná), ale už by nebylo bezopečné, aby se chytaly generické ovladače.

Ovladače z Windows 8 často jde nainstalovat i na Windows 7. Někdy, pokud to nechce projít instalátorem, dají se instalační EXE / MSI rozbalit (např. 7zipem) a z nich vzít pouze INF a SYS soubory a ty nainstalovat bez instalátoru. Třeba tím nebudou dostupné všechny funkce, ale aspoň systém bude umět ovládat zařízení (např. powermanagement).

Ale jak už jsem psal, neztrácel bych tím čas a už vůbec ne s operačním systémem, který je dnes už mrtev.

1364

Software / Re:Nvidia driver vyžaduje Intel driver

« kdy: 17. 03. 2019, 07:56:25 »

Ano, s touto úrovní znalostí můžu doporučit tři cesty:
a) pokud je na ntb recovery procedura na natažení předinstalace výrobce, využijte ji,
b) pokud není, stáhněte z Aceru všechny ovladače pro konkrétní model a nainstalujte je (intel ovladači se začíná),
c) pokud není k dispozici ani to, tak to dejte udělat někomu, kdo to zná, protože popsat všechny nuance správné instalace by bylo na velmi dlouho.

Ad c) Bývá zvykem nejprve instalovat ovladače čipsetu. Intel má na své stránce autodetekci, ale ta u straších modelů běžně nefunguje (nechtějí podporovat staré modely). Jako první se instaluje čipset, pak ovladač řadiče disků (ten může být v režimu SATA, RST, RSTe, RAID) - a je to o to komplikovanější, že tatáž technologie mění v čase jméno. Takže ovladač, který v době zakoupení notebooku měl nějaké označení, jeho nová verze se už může jmenovat jinak (nebo můžete použít starší verzi, ale proč?). Případně se doinstalovávají drobnosti typu řadiče USB a pod. (Např. pokud to má USB3).

Pak se instaluje ovladač zvukové karty.

Teprve pak ovladač grafiky (HDMI přenáší i zvuk, proto se instaluje až poté).

To je ale jen ve velmi, velmi hrubých rysech, abyste to vůbec rozběhal. Pokud chcete udělat opravdu dobrou instalaci, je to mnohdy složitější. Instalují se ovladače na kde co, např. na čtečky paměťových karet, aby měly správné ikony a skrývaly se, když není karta zasunuta, ovladače webcamu, myši (trackpadu), ...

Pokud chcete udělat instalaci dobrou, pak se z webu výrobce a ze správce zařízení sesbírají informace o jednotlivých kokponentách, ale ovladače se stáhnou přímo z webu jednotlivých dodavatelů komponent. Já doporučuji většinu obslužných programů neinstalovat, instalovat jen čisté drivery (nastavení pak řeší Windows, a ne nějaká aplikace třetí strany, která se po pár service packcích rozpadne).

Mnohem dál by Vás posunuly Windows 10, které mají velkou část ovladačů instalovanou přes Windows Update a opravdu v aktuálních verzích.

1365

Sítě / Re:Shorewall 5.x a alias veřejné IP

« kdy: 13. 03. 2019, 15:11:29 »

Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.

Máte pro takové doporučení nějaké zdůvodnění? Případně vysvětlení, co by to v tomto konkrétním případě řešilo?

Má to několik pozitivních dopadů. Maska na druhotných IP stejného subnetu víceméně nedává smysl. První definice nastaví interface routu, která už při dalších IP adresách není potřeba nastavovat. (Např. na broadcasty bude vždy odpovídat ta prvotní IP adresa, takže i z tohoto důvodu je maska zbytečná). Linux si s tímto sice umí poradit, ale proč spoléhat na automagii, když se to dá nastavit správně?

Dalším důvodem je prevence chyb administrátora. Kdyby v důsledku nějaké chyby vyrušil primární IP adresu, tak s maskou /32 nenaskočí na její místo; většinou je vhodnější, aby systém přestal odpovídat, než aby z ničeho nic fungoval nepředpokladatelně.

Posledním důvodem je, že můžete mít kombinaci X adres na stejném interface, ale z různých subnetů, např.:

192.168.0.1/24
192.168.0.2/24
10.0.0.1/24
10.0.0.2/24

Všechny současné OS spolehlivě dosadí tu první ip adresu jako primární. Ta bude odpovídat na broadcasty, z ní budou defaultovat nová spojení. Ale co v případě subnetu 10.0.0.0/24? Tam jsou obě adresy v rovnocenné pozici a nelze spoléhat na to, že každá distribuce (a ostatně i každá verze jádra) upřednostní 10.0.0.1. Řešením proto je:

192.168.0.1/24
192.168.0.1/32
10.0.0.1/24
10.0.0.2/32

Tím dáte systému jasně na srozuměnou, které adresy jsou hlavní.

BTW i na FreeBSD funguje nastavení masek i pro sekundární IP adresy, ale nedoporučuje se to. V Linuxu toto není nikde moc zdokumentované, spíš se předpokládá, že admin rozumí obecné síťařině.