Dlouholetý balíčkář KDE Jonathan Riddell končí. Jeho práci na KDE neon financovala firma Blue Systems, která ale končí (Clemens Tönnies, Jr., dědic jatek Tönnies Holding, ji už nebude sponzorovat), někteří vývojáři KDE se přesunuli k nově založené firmě Techpaladin. Pro Riddella se již nenašlo místo. Následovala debata o organizaci těchto firem, které zahraniční vývojáře nezaměstnávají, nýbrž najímají jako kontraktory (s příslušnými důsledky z pohledu pracovního práva).
V Amsterdamu probíhá Blender Conference 2025. Videozáznamy přednášek lze zhlédnout na YouTube. V úvodní keynote Ton Roosendaal oznámil, že k 1. lednu 2026 skončí jako chairman a CEO Blender Foundation. Tyto role převezme současný COO Blender Foundation Francesco Siddi.
The Document Foundation, organizace zastřešující projekt LibreOffice a další aktivity, zveřejnila výroční zprávu za rok 2024.
Byla vydána nová stabilní verze 7.6 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 140. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 1.90.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.25.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
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