Příspěvky

106

Server / Re:SFTP vs FTP bezpečnost

« kdy: 21. 04. 2019, 10:34:49 »

FTP je super lightweight, SFTP (powered by SSH subsystem) bude pomalejsi

Tazatel mluví o "vystrčení portu do Internetu", takže podle všeho řeší přístup přes Internet. Opravdu si myslíte, že má tak rychlé připojení na Internet a tak pomalý procesor, aby ssh protokol způsobil viditelné zpomalení?

107

Hardware / Re:Jakou bezzrcadlovku?

« kdy: 10. 04. 2019, 22:48:33 »

...profi skla, ktere jsou must-have abys z te zrcadlovky udelal znatelne lepsi fotky nez soucasnymi mobily ktere ti snimky domaluji skrze AI.

Stačí mít v záběru trochu složitější texturu (skvěle poslouží třeba trávník nebo koruna stromu) a všechny ty "AI" mobilů, které údajně tak skvěle fotí, jsou v koncích a na fotce vytvoří neuvěřitelnou mazanici i za perfektních světelných podmínek. Znatelně lepší fotku pak udělá i entry level zrcadlovka se setovým objektivem; s objektivem na úrovni třeba mého oblíbeného Tamronu 17-50 f/2.8 (který bych se zdráhal označit za "profi sklo") pak bude kresba úplně někde jinde.

108

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

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

Dobrá, pokusím se ty polopravdy trochu uvést na pravou míru.

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ě?

Především proto, že to není žádná automagie a proto, že když to nastavíte správně, funguje to zcela deterministicky a v souladu s dokumentací. O primární a sekundárních adresách má smysl mluvit pouze v případě, že se jedná o adresy se stejným přiřazeným rozsahem - a to pro každý z těch rozsahů zvlášť. Takže ve vašem příkladu

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

jsou (pokud je přidáte v tomto pořadí) adresy 192.168.0.1 a 10.0.0.1 primární a ty zbylé dvě sekundární, což si můžete snadno ověřit podle příznaku secondary ve výstupu "ip addr show". Proto skončíte se dvěma automatickými routami, které se přidají spolu s primárními adresami, zatímco při přidání sekundární adresy se žádná routa nepřidává. Žádná magie...

Pokud ovšem adresy nemají stejný rozsah, pak mezi sebou žádný vztah primární/sekundární nemají a routa se přidává pro každou z nich. (Dokonce můžu přidat dvakrát stejnou adresu se dvěma různými délkami prefixu.) Viz např.

Kód: [Vybrat]

lion:~ # ip link add dummy1 type dummy
lion:~ # ip link set dummy1 up
lion:~ # ip addr add 172.17.1.1/24 brd + dev dummy1
lion:~ # ip addr add 172.17.1.2/24 brd + dev dummy1
lion:~ # ip -4 addr show dev dummy1
23: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 172.17.1.1/24 brd 172.17.1.255 scope global dummy1
       valid_lft forever preferred_lft forever
    inet 172.17.1.2/24 brd 172.17.1.255 scope global secondary dummy1
       valid_lft forever preferred_lft forever
lion:~ # ip route show dev dummy1
172.17.1.0/24 proto kernel scope link src 172.17.1.1 

lion:~ # ip addr flush dev dummy1
lion:~ # ip addr add 172.17.1.1/24 brd + dev dummy1
lion:~ # ip addr add 172.17.1.2/26 brd + dev dummy1
lion:~ # ip -4 addr show dev dummy1
23: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 172.17.1.1/24 brd 172.17.1.255 scope global dummy1
       valid_lft forever preferred_lft forever
    inet 172.17.1.2/26 brd 172.17.1.63 scope global dummy1
       valid_lft forever preferred_lft forever
lion:~ # ip route show dev dummy1
172.17.1.0/26 proto kernel scope link src 172.17.1.2 
172.17.1.0/24 proto kernel scope link src 172.17.1.1 

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ě.

Právě proto existuje /proc/sys/net/ipv4/conf/*/promote_secondaries, abyste si mohl (globálně nebo per interface) zvolit, jaké chování chcete, a nemusel vymýšlet podivné triky, které zamlží, kam která adresa vlastně patří. Buď se s primární adresou odstraní i všechny k ní patřící sekundární nebo (default) se primární stane další v pořadí. Ani v jednom případě nic "nepředpokladatelného", všechno je krásně deterministické a jasně zdokumentované. A obě varianty jsou lepší, než když vám tam zůstane viset druhá adresa s prefixem /32, takže něco bude fungovat dál a něco ne.

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.

Proč si před tím, než něco takového napíšete, neověříte, jak se ten systém opravdu chová?

spíš se předpokládá, že admin rozumí obecné síťařině.

Jedna z mála věcí, se kterými ve vašem příspěvku souhlasím.

109

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

« kdy: 13. 03. 2019, 14:53:26 »

Diky moc za odezvu. Takze pokud tomu rozumim, takze pokud je primarni rozhrani (enp0s31f6 -j MASQUERADE) tak si na muzu delat, co chci, ale SNAT pro subnet a enp0s31f6:0 proste nepojede.

Měl byste začít tím, že konečně pochopíte, že žádné rozhraní enp0s31f6:0 neexistuje. Už dvacet let ne. Máte jen jedno rozhraní a na něm dvě IP adresy. Target SNAT vám umožňuje specifikovat, na kterou zdrojovou adresu se mají které pakety překládat, to je všechno, žádnou mystiku v tom nehledejte.

110

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

« kdy: 13. 03. 2019, 11:34:31 »

V linuxovych manualoch sa nic take nepise, ale freebsd odporuca pouzivat pre aliasy masku 32 bitovu.Vysvetlenie v linku.

Ať koukám, jak koukám, vysvětlení se odkazuje na implementační detaily routovacích tabulek ve FreeBSD, které jsou pro Linux zjevně irelevantní (protože to, co se tam píše, na Linuxu není pravda).

111

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

« kdy: 13. 03. 2019, 09:39:45 »

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?

112

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

« kdy: 12. 03. 2019, 22:03:34 »

Jen jsem ted pridal na venkovnim rozhrani alias s dalsi verejnou IP. Zvenci mi alias odpovida stejne jako fyzicke rozhrani.

IP aliasing existoval naposledy v jádrech řady 2.0 (a dost možná pouze v jádrech řady 2.0), od jádra 2.2.0 (které vyšlo v lednu 1999) žádné aliasy neexistují a rozhraní má přiřazen pouze seznam adres. (Jen pro pořádek, dnes existují i ipvlan rozhraní, která se trochu podobají těm někdejším aliasům, ale fungují jinak a slouží k jinému účelu.)

Pokud chcete, aby určité pakety měly zdrojovou adresu přeloženu na druhou adresu odchozího rozhraní, použijte SNAT a napište přímo, jakou adresu chcete použít.

113

Software / Re:VMware Workstation a Player

« kdy: 11. 03. 2019, 23:49:19 »

Z mého pohledu je největší rozdíl v tom, že Workstation Pro umožňuje běh více VM současně a běh VM na pozadí (tj. bez spuštěného GUI) a také snapshoty VM. Přehled dalších rozdílů je např. tady.

114

Sítě / Re:Odstítění WiFi od sousedů

« kdy: 07. 03. 2019, 22:58:05 »

Vzhledem k tomu, že 5GHz neprojde snad ani přes dvě tenké zdi...

5GHz wifi je k ničemu hned, jak projdete do vedlejší místnosti. Není to řešení.

Reality check: zkusil jsem to teď ze zvědavosti na notebooku vedle na stole. Přes dvě cihlové třicítky zdi (a nějaký nábytek) není signál pochopitelně žádná sláva a je samozřejmě slabší než 2.4GHz ze stejného AP, ale i tak přes 5GHz protlačím víc než přes 2.4GHz. Tož tak...

Příloha pak ukazuje typický přehled toho, co bylo kolem k vidění za posledních 24 hodin: 9x 2.4 GHz, 0x 5GHz. Obvykle ten poměr  bývá tak 10:1.

115

Hardware / Re:Tip na ergonomickou klávesnici

« kdy: 27. 02. 2019, 20:47:17 »

Ono to hodně záleží na tom, co programujete a jaké prostředí k tomu používáte. Když jsem kdysi používal vývojová prostředí od Borlandu, ať už v DOSu nebo ve Windows, používaly se tam Fn klávesy a kombinace s nimi opravdu hodně. Dnes, kdy většinu vývoje obstarávám ve vimu a command line nástrojích (git, make, ...), je používání Fn kláves spíš nepraktické, takže je většinou používám jen na přepínání ploch.

116

Sítě / Re:Nový WiFi Router - byt 3+1 (panelový dům)

« kdy: 24. 02. 2019, 13:38:32 »

Při rozhodování nezapomínejte na to, že pro ovládání UniFi zařízení bude potřeba buď mít někde po ruce počítač, na kterém rozběhnete jejich UniFi Controller (což nemusí být úplně triviální, nemáte-li Ubuntu nebo Debian - na druhou stranu, stačí na to i třeba RPi 3), nebo si pořídit jejich "hardwarový" Cloud Key (což nejspíš bude něco dost podobného tomu RPi). Jinak řečeno, při více zařízeních od Ubiquiti je centralizovaná správa výhoda, ale na jeden AP je to spíš komplikace.

Co se týká toho Long Range AP, to je možná trochu overkill. Já mám v rodinném domku dva AP AC Lite, jeden v dolním patře a jeden v horním, a zatím jsem nedokázal pořádně vyzkoušet handover, protože jsem v domě nenašel místo, kde by byl signál kteréhokoli z nich tak slabý, aby to notebook vzdal a přepnul na druhý. :-)

117

Sítě / Re:Problém s fragmenty IPv6

« kdy: 17. 02. 2019, 21:50:48 »

U IPv4 ji podle zprávy z commitu z obav neudělali

Jen pro úplnost: důvod, proč analogické omezení u IPv4 neprošlo, byl především ten, že u IPv4 může fragmentovat kdokoli po cestě, takže se může stát, že už jednou fragmentovaný paket bude muset někdo cestou přefragmentovat na o něco kratší MTU. V takovém případě je normální, že někde uprostřed vznikne krátký fragment i při té "standardní" strategii, např. 3000 → 1500+1500+40 (MTU 1500) → 1480+40+1480+40+40) (MTU 1480).

118

Sítě / Re:Problém s fragmenty IPv6

« kdy: 17. 02. 2019, 21:37:23 »

...takže ten commit se asi v dohledné době bude revertovat, ale nejdřív bude potřeba změnit implementaci fragment queue pro IPv6 na rbtree (místo lineárního seznamu), stejně jako to už je u IPv4.

Ta změna už je v net-next stromě a měla by se tedy dostat do 5.1-rc1.

119

Sítě / Re:Problém s fragmenty IPv6

« kdy: 17. 02. 2019, 21:23:03 »

Nezahazují se samozřejmě všechny fragmenty kratší než IPV6_MIN_MTU (1280), ale jen ty, které nejsou poslední. Idea je taková, že standardní implementace seká paket podle MTU a do posledního fragmentu dá zbytek. Cílem toho patche bylo omezit rizika útoků typu FragmentSmack, které se snaží zatížit CPU příjemce posíláním velkého počtu nesmyslných fragmentů (ideálně co nejkratších).

Bohužel se ukázalo, že existují i reálné implementace, které rozdělují paket do fragmentů jinak, takže ten commit se asi v dohledné době bude revertovat, ale nejdřív bude potřeba změnit implementaci fragment queue pro IPv6 na rbtree (místo lineárního seznamu), stejně jako to už je u IPv4.

120

Hardware / Re:Bolest při psaní na mechanické klávesnici

« kdy: 09. 01. 2019, 10:06:13 »

Zrovna HyperX Alloy FPS jsem začal před časem používat, ale v "brown" variantě. Ze začátku mi hodně vadil naprosto tvrdý doraz, ale postupně jsem přizpůsobil styl psaní tak, abych nešel až do dorazu, nebo aspoň jen lehce; subjektivní pocit při psaní se tím hodně zlepšil. U "red", kde není žádná odezva ("prokliknutí" - i u "brown" je podstatně slabší, než jsem čekal), je to ale asi těžší.