PlayStation Network (PSN) má již několik hodin, vlastně celou sobotu, masivní výpadek (Stav služby PSN, X).
Vývojáři open source storage platformy TrueNAS oznámili, že s verzí 25.04 s kódovým názvem Fangtooth končí TrueNAS CORE postavený na FreeBSD a TrueNAS SCALE postavený na Linuxu. Jejich společným pokračováním bude TrueNAS Community Edition postavený na Linuxu.
Mapy Google dnes slaví 20 let. Spuštěny byly 8. února 2005. Svět se přesunul od papírových map k digitálním. A ke Street View, Live View, Immersive View, …
Hector "marcan" Martin, vedoucí projektu Asahi Linux aneb Linux na Apple Siliconu, skončil jako upstream vývojář linuxového jádra. Se slovy "už nemám žádnou důvěru v proces vývoje jádra … další vývoj Apple/ARM bude pokračovat downstream" odstranil své jméno ze souboru MAINTAINERS. Důvodem jsou neshody kolem Rustu v linuxovém jádru [Hacker News, No rust code in kernel/dma, please.].
Mistral AI včera představil nový vylepšený Le Chat. Nově také jako aplikace pro iOS a Android.
Britské bezpečnostní orgány nařídily americké firmě Apple, aby vytvořila takzvaná "zadní vrátka", která by umožnila dostat se k šifrovanému obsahu uživatelů uloženému v cloudu. Tajné nařízení, vydané v lednu, vyžaduje plošný přístup k šifrovanému účtu jakéhokoliv uživatele přístrojů Apple kdekoliv na světě. Britské úřady tedy Apple nežádají pouze o asistenci s přístupem k účtu konkrétního uživatele, ale rovnou chtějí mít přístup ke všem účtům, kdykoliv budou chtít.
Byla vydána (𝕏) lednová aktualizace aneb nová verze 1.97 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.97 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Nedávno se povedlo do pdf souborů vložit Tetris a DOOM a po otevření příslušného pdf souboru v na Chromiu založeném webovém prohlížeči vybranou hru přímo v pdf spustit. LinuxPDF ukazuje, že do pdf lze vložit také RISC-V emulátor a rozběhnout Linux.
Kancelářský balík LibreOffice byl vydán ve verzi 25.2. Podrobnosti v poznámkách k vydání.
Destination Gateway Flags Refs Use Netif Expire default 10.10.0.1 UGSc 14 103 en1 10.10/24 link#5 UCS 1 0 en1 10.10.0.1 0:60:94:fb:42:c8 UHLW 16 1687 en1 1006 10.10.0.105 127.0.0.1 UHS 0 5 lo0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 11 2651 lo0 169.254 link#5 UCS 0 0 en1vše je směřováno na bránu, server 10.10.0.1, což je žádoucí. Tam ovšem řeším problém, tam je výpis následující, ale nemohu donutit systém ať ping proběhne na stroje za OpenVPN tunelem, který je vidět v tabulce počítače 10.10.0.1, viz:
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 217.112.163.128 0.0.0.0 255.255.255.192 U 0 0 0 wlan0 10.0.0.0 192.168.0.1 255.255.255.0 UG 0 0 0 tun0 10.10.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 217.112.163.129 0.0.0.0 UG 0 0 0 wlan0Na počítači 10.10.0.1 bez problému pingnu na druhou stranu tunelu, což je žádoucí, ale toto neplatí na jiném počítači ze segmentu 10.10.0.0/255.255.255.0, i když dle mého uvažování by neměl být žádný problém, nebo tam něco někdo vidíte? Ping na jiné adresy není problém, ten jede bez problémů. Cílem je vynutit komunikaci ze segmentu 10.10.0.0/255.255.255.0 (jedna síť) se segmentem 10.0.0.0/255.255.255.0 (druhá síť), která je na druhém konci tunelu.
Co na tom klientovi ukáže 'ip route get 10.0.0.1'? Máte povolený forwarding? Ztrácejí se dotazy nebo odpovědi? Kde přesně ten paket mizí?
Výpisy příkazu route jsou dost nepřehledné (a někdy i neúplné). Ukazujte raději výpisy 'ip route show'.
23:54:56.094284 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 0 23:54:57.095105 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 1 23:54:58.094966 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 2 23:54:59.096577 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 3 23:55:00.097595 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 4 23:55:01.099313 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 5 23:55:02.100559 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 6 23:55:08.665637 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 0 23:55:08.666047 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 0 23:55:09.666950 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 1 23:55:09.667277 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 1 23:55:10.667581 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 2 23:55:10.667974 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 2 23:55:11.670649 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 3 23:55:11.670981 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 3 23:55:12.670154 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 4 23:55:12.670549 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 4 23:55:23.710750 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 0 23:55:23.726170 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 0 23:55:24.711886 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 1 23:55:24.727848 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 1 23:55:25.712656 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 2 23:55:25.724074 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 2 23:55:26.713146 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 3 23:55:26.727620 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 3 23:55:27.715368 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 4 23:55:27.730529 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 4 27 packets captured 27 packets received by filter 0 packets dropped by kernel
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ip route get <ip> se da nahradit route get <ip>
64 bytes from 10.10.0.1: icmp_seq=1 ttl=64 time=3.111 ms 64 bytes from 10.10.0.1: icmp_seq=2 ttl=64 time=3.015 ms 64 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=4.265 ms 64 bytes from 10.10.0.1: icmp_seq=4 ttl=64 time=3.110 ms 64 bytes from 10.10.0.1: icmp_seq=5 ttl=64 time=4.154 ms 64 bytes from 10.10.0.1: icmp_seq=6 ttl=64 time=3.053 ms 64 bytes from 10.10.0.1: icmp_seq=7 ttl=64 time=3.147 msa obráceně:
64 bytes from 10.10.0.105: icmp_seq=0 ttl=64 time=2.0 ms 64 bytes from 10.10.0.105: icmp_seq=1 ttl=64 time=173.4 ms 64 bytes from 10.10.0.105: icmp_seq=2 ttl=64 time=196.6 ms 64 bytes from 10.10.0.105: icmp_seq=3 ttl=64 time=16.4 ms 64 bytes from 10.10.0.105: icmp_seq=4 ttl=64 time=40.8 ms 64 bytes from 10.10.0.105: icmp_seq=5 ttl=64 time=64.0 ms 64 bytes from 10.10.0.105: icmp_seq=6 ttl=64 time=88.0 ms 64 bytes from 10.10.0.105: icmp_seq=7 ttl=64 time=112.4 msi toto mě lehce mate, sice je mezi tím AP, ale to by snad na úrovni TCP/IP mělo být jen průchozí, žádný filtr ani omezení AP nemá aktivováno.
Tiskni
Sdílej:
