Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Textový editor Zed dospěl do verze 1.0. Představení v příspěvku na blogu.
Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
VNC server wayvnc pro Wayland kompozitory postavené nad wlroots - ne GNOME, KDE nebo Weston - byl vydán ve verzi 0.10.0. Vydána byla také verze 1.0.0 související knihovny neatvnc.
Bylo oznámeno vydání Fedora Linuxu 44. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »David Malcolm se na blogu vývojářů Red Hatu rozepsal o vybraných novinkách v GCC 16, jež by mělo vyjít v nejbližších dnech. Vypíchnuta jsou vylepšení čitelnosti chybových zpráv v C++, aktualizovaný SARIF (Static Analysis Results Interchange Format) výstup a nová volba experimental-html v HTML výstupu.
Byla vydána verze R14.1.6 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
cat /etc/network/interfaces auto eth0 iface eth0 dhcp dns-nameservers XX.XX.XX.XXX XX.XX.XX.XXppp0 dostane IP v jiném segmentu.
1. Pouzite bud: networkmanager, ktory tusim dokaze zabranit rekonfiguracii nameserverov v resolv.conf, alebo ich v nastaveniach pptp/ppp zakazte prijimat.
2. Defaultne je presmerovany po vytvoreni VPN PPTP spojenia cely trafic cez tunel. takze toto dokazete ovplyvnit len tak, ze zakazete default routu na VPN (ale iba staticke do danej siete za VPN) ... opat to dokaze networkmanager, resp konfiguracia VPN cez neho.
Navenek se již správně identifikuji v lokaci Morava :o)
Jenom ten resolv se furt přepisuje, může se mi tím zpomalovat internet pokud to používá DNS které jsou v Praze na VPN ?IPSec gateway XX.XX.XX.XX IPSec ID aaa IPSec secret aaa #IKE Authmode hybrid Xauth username aaaa Xauth password aaaa
Problém je že já do té sitě mám jen IP , jmeno a heslo a tak jsem do IPSec ID a IPSEC secret dal to samé co do username a password.
sudo vpnc praha vpnc: no response from target
To se bohužel nespoji :o).Osobně bych to raději připojoval pomoci scriptu ihned po startu kompu. Ale jaksi nevím jak na to .o). S těmi klikátkami si nějak nerozumím.
hehe :)), Neviem preco sa nechate tak lahko zblbnut otazkou pouziteho VPN klienta. Ved predsa sam ste pisal, co pouzivate na pripojenie ... VPNka je typu PPTP (point-to-point tunneling protocol), teda na pripojenie potrebujete na strane klienta pptp. Ten urcite nainstalovany mate pretoze ho pouziva networkmanager pre vytvorene VPN spojenie, ktore teraz riesite.
Vo vnutri pptp sa pouziva protokol ppp, cez ktory sa jednak autentifikuje klient, predavaju staticke smery ale aj nastavuju DNS a WINS servery. Takze to, co potrebujete riesit je ppp.
Ale to je v poriadku ze ste napisali sem :) Ja som komentoval to, ze aj napriek tomu ze ste pisali o pouzitej VPNke ako PPTP ste zacali skusat klientov ktori s nim nemaju nic spolocne. Ale berem ze to mohla byt neznalost.
A serveru urcite viac VPN robit problemy nebude. Dolezite je vypnut prepisovanie default routy. A ten zbytok predchadzajucej rady plati.
Tak sláva :o) právě jsem se bez klikátek připojil do 2 VPN sítí.
1. připojení jsem musel realizovat pomocí vpnc jelikož bylo na druhé straně CISCO :o)-.
sudo apt-get install vpnc #vytvořit konfigurák pro připojení sudo nano /etc/vpnc/nekam.conf #obsah nekam.conf IPSec gateway IPADRESASERVERU IPSec ID jemnoskupiny IPSec obfuscated secret ZDE ZASIFROVANE GROUP HESLO Xauth username vaseprihlasovacijmeno sudo vpnc nekam.conf #budete vyzvani k zadani hesla. a pokud je vse ok pripoji se to #vytvori se vam nove sit. zarizeni tun0 #odpojeni z VPN sudo vpnc-disconnect
Druhé připojeni jsem musel realizovat pomocí pptd
sudo apt-get install pptp-linux mppenc binutils
pak se připojíte pomocí třeba takového příkazu
sudo pptpsetup --create PRAHA --server praha --username mujucet --password mojeheslo --encrypt mppe-128 --start #vytvoří se nové sit. zarizeni ppp0 #odpojeni z VPN sudo pptpsetup --delete PRAHA
Samozřejmě to jde všechno napsat do nějakého scriptu a automaticky spouštět třeba po startu , tohle tady uvadím jen na oťukání že se to spoji a že spojeni funguje. :o) Doufám že to někomu pomůže :o)
Stále ovšem bojuji s přepsáním resolv.conf , jakmile se připojím do těch dvou VPN tak rychlost připojení k internetu se rapidně sníží, přepíše se resolv.conf a připisuji to hlavně tomu.
Do rc.local jsem připsal tohle :
#automatické připojeni po startu vpnc praha.conf iptables -A FORWARD -i tun0 -o eth0 -s 192.168.0.0/24 -m state --state NEW -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A POSTROUTING -t nat -j MASQUERADE route add -net 192.168.17.0 netmask 255.255.255.0 dev tun0 #to same na ppp0
moje IP ADRESY NA serveru
WLAN = ETH1 = DHCP /dostanu od providera/
LAN = ETH0 = 192.168.0.1 /tady běží DHCP server
tun0 = 192.168.17.15
ppp0 = 192.168.57.? ruzně :o)
Tak jsem tam to pravidlo přidal.
DNSUpdate noresolv.conf to už nepřepisuje. Nastal však druhý problém a to že v ten moment se již nedostanu na počítače v té VPN . Celý problém vidím v routování.
Pokud zavedu pravidlo
route del default route add default gw MOJESTARABRANA route add -net 192.168.17.0 netmask 255.255.255.0 dev tun0Tak se z mého kompu dostanu na net /resolv.conf stale zůstává stejný / ale nedostanu se na kompy v té VPN, pokud toto pravidlo zakážu dostanu se na kompy v VPN ale již se nedostanu na internet /myšleno nedopingnu se třeba na www.seznam.cz ani nikam jinam co potřebuje překlad adres , normálně na IP seznamu se dopingnu./ Tudíž někde hapruje překlad adres , a já fakt nevím kde :o)).
Přikládám diagram sítě plná čara je normalní připojení internet , přerušovaná je VPN připojení. Pokud by se někdo našel pomoci mi s realizaci byl bych vděčen.
Patrně pomocí bridge se ty LANky propoji ale mé síly na to nestačí :o) .
Muselo se správně naroutovat :o) ."DNSUpdate no" jsem použil DNS jsou ted ty servrovní :o)./už to nepřepisuje/ Stačilo přidat do routovací tabulky subnety /se stenou maskou/ které jsou za VPNkami do kterých se server připojuje. , pak v konfigurační souboru openvpn serveru povolit naroutování všech subnetu které jsou na serveru. /pomocí "pusch"/ /subnety opět všechny se stejnou maskou ! - zde jsem dělal chybu/
Tímto děkuji Davidovi který mě nakopnul správným směrem :o).Vše funguje :o))
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz