Poslední příspěvky

91

Server / Re:Virtualizace Hyper-V vs. VM

« Poslední příspěvek od Marek Staněk kdy 02. 10. 2024, 14:06:23 »

Ono se to do určité míry dá omezit tím, že hypervisor bude v izolované VLAN, takže ze strany managementu se do něj půjde dostat jen ze správcovské stanice, ale to samozřejmě nechrání před útokem cestou "vyskočení ze sandboxu" v důsledku nějaké neopravené chyby.

92

Server / Re:Obnova RAID 1

« Poslední příspěvek od Marek Staněk kdy 02. 10. 2024, 14:03:57 »

Pokud máš dost šachet pro disky, jsou proti postupu "záloha - výměna vadného - rebuild - výměna starého - rebuild" podstatně šetrnější (protože počet operací na starém disku bude v nejhorším případě poloviční, což u hodně starých disků může hrát roli rozdílu mezi záchranou dat a kolapsem dosud fungujícího zbylého disku se ztrátou dat) alternativní postupy:
1)
- zřídit vedle RAID z nových disků
- data překopírovat (objem přenosů a operací obdobný záloze)
- starý RAID zrušit

nebo
2)
- stávající RAID rozšířit o dostatek nových disků
- rebuild
- staré disky z RAIDu vyřadit

Každopádně bych pro příště doporučil ochranu dat řešit trochu dřív, než vznikne nějaký technický problém, nejlépe nastavením nějakého rozumného zálohovacího plánu už jako součást postupu záchrany.

93

Hardware / Re:Nový monitor na práci vývojáře

« Poslední příspěvek od Filip Jirsák kdy 02. 10. 2024, 13:55:48 »

Předřečník jasně reagoval na to, že při použití lupy přijdeš o plochu a tedy je nejlepší použít nativní rozlišení s nativním scale 100% a máš si podle toho vybrat takový monitor. Stojíš si na vedení

Koukám, že je tu v tom pěkný zmatek. Dříve se aplikace navrhovaly na konkrétní velikost písma a obrazovky aplikace byly navržené v pixelech. Tj. třeba velikost tlačítka byla 80 px, a bylo jasné, že se tam název tlačítka vejde, protože se použil systémový font v konkrétní velikosti, takže ten nápis byl pořád stejný. Byla tedy daná pevná velikost v pixelech a z toho a rozlišení vyplynula fyzická velikost na monitoru. Pokud někdo opravdu špatně viděl, mohl použít softwarovou lupu, což znamenalo, že se ta bitmapa vykreslovaná normálně na obrazovce zvětšila. Když to byl celočíselné násobky, tak se třeba jeden pixel zobrazil jako čtyři pixely do čtverce. Neceločíselná lupa znamenala rozmazání.

Nyní si můžete v systému nastavit škálování, což znamená, že se má všechno zobrazit třeba ve velikosti 125 %. Aby to správně fungovalo, musí aplikace vše vykreslovat vektorově a uplatňovat i to nastavené škálování. Problém bude se starými aplikacemi, které tohle nepodporují, a zobrazí se bez toho škálování. Dříve ještě býval problém s tím, že některá aplikace použila to škálování třeba jen na text, ale ostatní prvky neškálovala – takže se obrazovka aplikace rozsypala. S tím už dnes problém nebývá. Některé aplikace ještě mívají problém s tím, když máte víc obrazovek a to škálování je na nich nastavené různě – některé aplikace pak škálují podle obrazovky, na které se zobrazily poprvé, a když přesunete okno jinam, nepřizpůsobí se to.

Tvrdit, že je dobré mít nastavené škálování na 100 %, je nesmysl – protože to odpovídá schopnostem obrazovek před deseti patnácti lety. Dneska, když máte stejně velký displej, jako před deseti lety, ale máte tam o půlku větší rozlišení, nechcete mít fyzickou velikost prvků (textů apod.) 2/3 toho, jak to bylo před těmi deseti lety. Protože sedíte pořád stejně daleko od displeje, nevidíte lépe, takže dvoutřetinové písmo nepřečtete. Nemluvě o tom, když máte retina displej a to písmo by bylo poloviční. To vyšší rozlišení displeje chcete použít na to, aby písmo bylo jemnější a ostřejší, ne menší – nebo-li ve pixelech musí být větší. A k tomu právě slouží to škálování.

(Tím, že se na lepším rozlišení zobrazí písmo jemnější a ostřejší, zvládne člověk přečíst o něco menší písmo. Takže po určitou dobu se zvětšovalo rozlišení, zůstávala velikost zobrazovacího zařízení a škálování se neřešilo, takže fyzická velikost písma se zmenšovala, ale pořád to šlo přečíst. Ale se 4K nebo retina displeji už by to bylo příliš prťavé a nečitelné, kdyby se všechny objekty na displeji nezvětšovaly.)

Tj. to škálování se používá pro vektorové vykreslování (žádné rozmazané zvětšování pixelů) a určuje to poměr mezi logickými pixely (ve kterých udává rozměry autor aplikace) a fyzickými pixely (které umí zobrazit displej a které se v poslední době zmenšovaly (a někde kus za retina displeji už to zmenšování skončí, protože zmenšovat to dál výrazně pod rozlišovací schopnost oka nemá smysl).

94

Server / Re:Porizeni domaciho serveru na Proxmox

« Poslední příspěvek od alex6bbc kdy 02. 10. 2024, 13:51:29 »

tak musi to jet v kuse? pokud chces ticho, tak dej vodnika na chlazeni.

ja bych chtel zkusit ty mnohojadrove procesory arm ampere na virtualizaci.

zkusit si to, ale muzes na cemkoliv.

ipmi, remote management se u domacich kompu resi pomoci rpi krabicek, ktere mohou zvenku uvladat pc.

95

Server / Pořízení domácího serveru na Proxmox

« Poslední příspěvek od Jix0 kdy 02. 10. 2024, 13:34:14 »

Dobry den.

Rikal jsem si, ze bych si chtel poridit domu nejaky trochu vykonnejsi hardware, ktery bych mel doma jako server. Aktualne tam mam minipc s Atom x-z8350 a premyslel jsem puvodne nad porizenim nejakeho starsiho Dell PowerEdge, napriklad R530 nebo R630, pripadne tower varianty jako T330. U rack verzi me ale trochu odrazuje spotreba a hlucnost, precejen bude server v byte, v mistnosti vedle loznice. Zenu a deti nemam, takze tem to vadit nebude, ale poslouchat v noci 50 db z vedlejsi mistnosti nebude idealni. Pripadne poridim nejake Xeony s nizkym TDP, to by mohlo spotrebu a hluk snizit.

Prvne bych se chtel ale poradit a tak napisu specifikace, co bych primarne potreboval aby server mel.

Velikost 2U nebo Tower, Dual CPU (neni uplne ale nutnost), minimalne 16 core, ci 10 core v pripade Dual CPU, minimalne 8 RAM slotu DDR4, RAID pole s hotswap disky, PCIexpress sloty, 2x Gbit LAN, nejaka varianta remote managementu - IPMI, iDRAC, etc.,

Jeste jsem uvazoval postavit to na beznem domacim HW, jen bych zvolil CPU s dostatkem jader s HT a situaci by to taky mohlo resit. Akorat nevim o desktop zakladnich deskach, ktere by mely IPMI nebo neco podobneho. Remote management bych tam docela potreboval.

Bude se na tom provozovat Proxmox a v nem nejake virtualy, presunu tam svuj stavajici server, bude slouzit jako NAS, kamerovy server, v budoucnu mozna i jako router a dalsi takova vyuziti.

Jak to mate vy doma? Provozujete vyrazeny serverovy HW, nebo jste si staveli neco vlastniho? Budu rad za rady a tipy.

Dik za odpovedi

96

Hardware / Re:Nový monitor na práci vývojáře

« Poslední příspěvek od Filip Jirsák kdy 02. 10. 2024, 13:29:44 »

Pro sdílení FullHD části na 4K UW monitoru přes MS teams doporučuji sadu nástrojů Power Toys a z ní FancyZones - to je skvělé samo o sobě pro správu oken/zón na velkém monitoru. Pak už to stačí jenom skombinovat s Region to Share nástrojem a v MS teams sdílet tuto aplikaci - funguje pak krásně jako FullHD monitor.

Díky. Ještě bych potřeboval něco podobného pro MacOS – sdílím z obou systémů.

97

Server / Re:Certifikáty na souborovém systému jen ke čtení

« Poslední příspěvek od Filip Jirsák kdy 02. 10. 2024, 13:16:02 »

Akú má výhodu komerčný certifikát, resp. certifikát od inej CA ako Let's Encrypt?

Aktuálně vydávají komerční CA certifikáty s roční platností. Takže pokud nemůžete použít automatizaci přes ACME protokol a musíte certifikáty řešit a někam nahrávat ručně, je jednodušší to dělat jednou za rok než 4–5 krát za rok. Ale jsou tlaky na zkrácení platnosti certifikátů, takže pravděpodobně i ty komerční CA budou někdy donucené platnost certifikátů ještě zkrátit.

Tiež som celkom nepochopil s tým HSM. Predpokladám, že k serveru nebudem mať prístup (cloud), takže TLS bude bežať s privátnym kľúčom z úložiska cloudu.

To chce vybrat nějaký důvěryhodný cloud, a pak s tím klíčem rozumně pracovat. Ideálně pokud ten cloud má nějaké úložiště citlivých informací a dá se to nějak rozumně dostat do aplikace (aby to nebyl soubor na disku, který bude moci přečíst i ta aplikace běžící na webovém serveru, nebo dokonce jiné aplikace běžící na stejném serveru).

V tomhle případě je hodně důležité, jaká bude povaha těch dat, která ta zařízení budou odesílat. Pokud to bude posílat teplotu ve skleníku u pár desítek či stovek českých klientů, pak se asi nestane nic vážného, pokud by ta data unikla nebo by je někdo zfalšoval. Pokud to bude něco, že z těch dat půjde odvodit, zda je někdo doma u desítek tisíc domácností po celém světě, nebo přes to půjde v podobném počtu domácností vypnout vzdáleně lednici, tak bych asi nešel do toho, že nějaká poměrně banální chyba může způsobit únik privátního klíče a já ho pak nebudu schopen zneplatnit.

Ja si len zapíšem u mňa na Trezor ten privátny kľúč pre prípad, že by som potreboval certifikát a kľúč opätovne uploadoval do cloudu (napríklad pre prípad, že by som službu so zdrojmi musel ešte raz definovať).

V tom případě musíte mít klíč uložen tak, aby byl exportovatelný, což nevím, zda Trezor umožňuje.

98

Server / Re:Certifikáty na souborovém systému jen ke čtení

« Poslední příspěvek od mark42 kdy 02. 10. 2024, 12:39:02 »

HSM je najbezpecnejsi sposob uschovy privatneho kluca. Je to bezpecnejsie ako mat ho niekde v beznom ulozisku, pretoze tam sa otvara moznost, ze hacker alebo admin ten kluc pouzije alebo skopiruje (vytiahne zo zalohy atd...) Oproti tomu samotne HSM len prijima poziadavky a za pouzitia PK ich vybavuje (napr. dodava podklady pre vytvorenie sifrovaneho spojenia, alebo podpisuje dokumenty).

99

Server / Re:Virtualizace Hyper-V vs. VM

« Poslední příspěvek od Vít Šesták (v6ak) kdy 02. 10. 2024, 12:38:40 »

No, nenasedal bych na mrtvého koně. Pokud novější verze ESXi nejsou k dispozici (resp. jsou, ale za peníze, které nechcete platit), stáhnout někde starší verzi sice lze, ale:

1. Věříte tomu zdroji, že ESXi nijak nemodifikoval.
2. Nemáte opravy zranitelností.

U něčeho, co bude fungovat jako hypervizor, bych si na to dával bacha, má přístup v podstatě ke všemu, co na počítači děláte.

100

Hardware / Re:Přepínání systémů na Raspberry Pi

« Poslední příspěvek od k3dAR kdy 02. 10. 2024, 12:23:37 »

[...] Nic v eeprom nastavovat nemusim.
Stači když v raspi-config - f6 andvanced options - boot loader vyberu M2 boot nebo SD a spusti se mi vybrany system.
To by nešlo vytvořit skript, který bý to někde přepsal a udělal reboot?

Ano, slo by vytvorit script... kterym bys prenastavoval eeprom, pomoci nastroje rpi-eeprom-config kterej mas popsanej na tom odkazu v prvni odpovedi ;-)
Protoze presne takto to dela rpi-config, podle toho zda vyberes moznost (B)1-SD nebo (B)2-NVMe, tak to do eeprom zapise...
Ale tim ze nemam RPi abych si to overil na realnem vystupu z eeprom, tak radeji nebudu zkouset psat jak by ten skript mel vypadat, ale v podstate jde o to ze presmerujes vystup z rpi-eeprom-config do souboru, pak v nem zmenis hodnotu BOOT_ORDER (kde ale se lisi krome SD ci NVMe jeste podle dalsich veci) a upravene to pak pres rpi-eeprom-config posles zpatky do eeprom...