Poslední příspěvky

1

Windows a jiné systémy / Re:Vlastnosti macOS pro linuxáka

« Poslední příspěvek od anonacct kdy Dnes v 15:23:06 »

Binding kláves je opravdu hell, a ono to ani nejde na macu udělat tak, jak to je v Linuxu. Na toto si člověk buď zvykne, nebo ne, já jsem si na to moc nezvyknul a nejlíp se mi dělá stejně v Linuxu, ale mac používám denně.

2

Sítě / Re:Venkovní síťový kabel na 300 m a 1 Gbit

« Poslední příspěvek od Martin Poljak kdy Dnes v 14:55:15 »

Já bych to za sebe uzavřel s tím, že rozsáhle teoretizovat o blescích do země se dá donekonečna (a také se tak skoro pod každým vláknem optika vs. metalika buhvíproč děje)

A v dobách, kdy jsem měl doma telefonní modem, opravoval jsem drobné škody po bouřce asi třikrát (na tom modemu). [...] Třeba má původní tazatel celou trasu někde v údolí, a vážně se tu projevuji úplně jalově.

Ano, to je totiž ono. Velmi záleží, kde bydlíte. Já za desítky let nikdy a nikde nezažil, že bych měl s něčím podobným jediný problém. A to máme domů několik a bydlel jsem za život alespoň na deseti místech. Připojení k internetu jsem jsem měl vždy kabelové.

Přemejšlím, kolikrát jsem zažil úder blesku někde hodně blízko. Jako že jsem nevnímal zpoždění mezi bleskem a hromem. No pár jich bylo.

Osobně snad jednou, možná dvakrát. Možná hlavně proto, že bydlíme pod obecním bleskosvodem v podobě kostela na náměstí nad námi. A když tedy nepočítám blesk co uhodil asi dvacet metrů odemne do stromu přimo před mýma očima venku na ulici.

3

Windows a jiné systémy / Re:Vlastnosti macOS pro linuxáka

« Poslední příspěvek od Marek Staněk kdy Dnes v 14:49:21 »

teda krome leskleho displeje, to jsem nevericne koukal ze leskly displej dnes nekdo mysli vazne

Lesklej displej bez dotykovky je ten úplně nejlevnější způsob, jak zvýšit jas a minimalizovat paralaxu při ukazování prstem na něco na displeji.

4

Sítě / Re:Venkovní síťový kabel na 300 m a 1 Gbit

« Poslední příspěvek od neregistrovany kdy Dnes v 14:48:41 »

starý telefonní pár, elektriká přípojka a pod, přičemž ty první dva jdou na venkově často i vzduchem. Pokud někde v okolí skutečně nešťastně uhodí blesk: Není pak už dost jedno, kudy vám to do baráku přiteče?

Počítal bych, že ty Vámi jmenované pojišťovna nebude rozporovat (ostatně ta silová elektrika má revizi, takže i když od toho vyhoří půlka spotřebičů, jste papírově v cajku), ale ve chvíli, kdy zjistí, že jste si tam natáhnul kábl a něco chytlo od něj, protože jste ho špatně uzemnil, tak budete mít asi problém.

na telefonní přípojku přece taky nemáte "revizi", o televizních koaxiálních svodech ze střechy rodinných domků už bych vůbec nemluvil...

Prostě: Nedělejme z pár nešťastných případů (vyjímek potvrzujících pravidlo) standard. Nic ze zde uvedeného mě nepřesvědčilo, že metalická zemní coax přípojka představuje nějaké reálné nebezpečí.

5

Server / Re:Nefunkční Nginx proxy_bind $remote_addr transparent

« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 14:45:13 »

No to aby provoz na cizi adresy smeroval do aplikace, to si ten nginx zaridi?

Pochybuju. To musí být nastaví routování v jádře – musí ty cizí IP adresy routovat jako by patřily danému počítači, aby je neroutoval pryč.

jak zjistim, ze ma caps_raw_net? spoustim ho pod rootem prikazem systemctl start nginx na LXC VPS. Vidim v htop :nginx master process ma root, workerirs maji www-data

Pokud hlavní prcoes běží pod rootem, nginx dokáže tu capability worker procesům předat.

Na ten vps se  ty pakety dostanou, to vidim z tcpdump. je ale potreba neco stelovat na firewallu, protoze kdyz o tom premyslim, jak vps/nginx pozna ,ze pakety SYN+ACK z tun SRC 192.168.5.BACKEND:443 DST 23.4.5.6:65444 maji projit nginxem? z komunikace projde jen prvni syn+ pak castecne syn-ack- dostane se na VPS a dal nevim.   nema tam taky byt nejaky ip rule  nebo mangle  i tady na vps? protoze v popisovane situace kde je jen port forwarding, sipackety odchyti pravidlo v prerouting ktere prepisuje je posila na 192.168.5.jinyserver

To je právě to, že tohle musí být nastavené v routovacích tabulkách jádra. Nevím z hlavy, jak se to dělá – ale standardně máte v routovací tabulce dvě možnosti. Jedna je, že se paket směruje na next hop dál do sítě, a druhá (která se normálně nastavuje jen pro lokální IP adresy), že se ten paket zpracovává lokálně a pošle se tedy naslouchající aplikaci. No a vy potřebujete, aby se ten druhý typ použil i pro pakety, které mají libovolnou cílovou IP adresu, zdrojový port je 443 a zdrojová IP adresa je adresa toho cílového serveru.

Jinak teda osobně bych se na tohle vykašlal, normálně bych nginx nastavil, ať to dál přeposílá pod svou IP adresou a IP adresu zdroje ať cpe do hlavičky X-Forwarded-For. Jaký máte důvod posílat to dál s tou původní IP adresou?

6

Sítě / Re:Venkovní síťový kabel na 300 m a 1 Gbit

« Poslední příspěvek od Wasper kdy Dnes v 14:37:46 »

starý telefonní pár, elektriká přípojka a pod, přičemž ty první dva jdou na venkově často i vzduchem. Pokud někde v okolí skutečně nešťastně uhodí blesk: Není pak už dost jedno, kudy vám to do baráku přiteče?

Počítal bych, že ty Vámi jmenované pojišťovna nebude rozporovat (ostatně ta silová elektrika má revizi, takže i když od toho vyhoří půlka spotřebičů, jste papírově v cajku), ale ve chvíli, kdy zjistí, že jste si tam natáhnul kábl a něco chytlo od něj, protože jste ho špatně uzemnil, tak budete mít asi problém.

7

Hardware / Re:PC sestava pro Linux

« Poslední příspěvek od František Ryšánek kdy Dnes v 14:23:00 »

Hmm, no, s virtualizací (Xen) nevím, jestli bych chtěl řešit afinitu k jádru. Tam mám o vrstvu víc.

Asi to nějak jde... přišpendlit guesta na konkrétní množinu jader. Zmiňují třeba virsh vcpupin ...

8

Sítě / Re:Venkovní síťový kabel na 300 m a 1 Gbit

« Poslední příspěvek od František Ryšánek kdy Dnes v 14:13:03 »

Já bych to za sebe uzavřel s tím, že rozsáhle teoretizovat o blescích do země se dá donekonečna (a také se tak skoro pod každým vláknem optika vs. metalika buhvíproč děje), ale do baráku vám vedou i další kovové kabely: starý telefonní pár, elektriká přípojka a pod, přičemž ty první dva jdou na venkově často i vzduchem. Pokud někde v okolí skutečně nešťastně uhodí blesk: Není pak už dost jedno, kudy vám to do baráku přiteče?

Ano :-)
Bleskojistku v přívodu NN jsem viděl cca prvně v životě asi před měsícem, kdy jsem ji osobně instaloval :-)
A v dobách, kdy jsem měl doma telefonní modem, opravoval jsem drobné škody po bouřce asi třikrát (na tom modemu).

Třeba má původní tazatel celou trasu někde v údolí, a vážně se tu projevuji úplně jalově.

Přemejšlím, kolikrát jsem zažil úder blesku někde hodně blízko. Jako že jsem nevnímal zpoždění mezi bleskem a hromem. No pár jich bylo.

9

Hardware / Re:PC sestava pro Linux

« Poslední příspěvek od Vít Šesták (v6ak) kdy Dnes v 14:04:48 »

Hmm, no, s virtualizací (Xen) nevím, jestli bych chtěl řešit afinitu k jádru. Tam mám o vrstvu víc.

10

Server / Re:Nefunkční Nginx proxy_bind $remote_addr transparent

« Poslední příspěvek od mikesznovu kdy Dnes v 13:57:49 »

No to aby provoz na cizi adresy smeroval do aplikace, to si ten nginx zaridi? 
jak zjistim, ze ma caps_raw_net? spoustim ho pod rootem prikazem systemctl start nginx na LXC VPS. Vidim v htop :nginx master process ma root, workerirs maji www-data
Na ten vps se  ty pakety dostanou, to vidim z tcpdump. je ale potreba neco stelovat na firewallu, protoze kdyz o tom premyslim, jak vps/nginx pozna ,ze pakety SYN+ACK z tun SRC 192.168.5.BACKEND:443 DST 23.4.5.6:65444 maji projit nginxem? z komunikace projde jen prvni syn+ pak castecne syn-ack- dostane se na VPS a dal nevim.   nema tam taky byt nejaky ip rule  nebo mangle  i tady na vps? protoze v popisovane situace kde je jen port forwarding, sipackety odchyti pravidlo v prerouting ktere prepisuje je posila na 192.168.5.jinyserver
conntrack -L mi hlasi SYNC RECV

a mimochodem jsem schopny  mit proxy_bind 10.0.20.31 transparent;  funkcni (ppokud vps priradim krome 10.0.20.1 i tuto) - jenze to mi nepomuze ,protoze pak positi jsou vsechny requesty s touhle sloucenou adresou akorat je tam 31 misto 1

a prirozene "proxy_bind $remote_addr ;" hlasi cannot bind.....