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.
Jon Seager z Canonicalu včera na Ubuntu Community Hubu popsal budoucnost AI v Ubuntu. Dnes upřesnil: AI nástroje budou k dispozici jako Snap balíčky, vždy je může uživatel odinstalovat. Ve výchozím nastavení budou všechny AI nástroje používat lokální AI modely.
Nový ovladač Steam Controller jde do prodeje 4. května. Cena je 99 eur.
Greg Kroah-Hartman začal používat AI asistenta pojmenovaného gkh_clanker_t1000. V commitech se objevuje "Assisted-by: gkh_clanker_t1000". Na social.kernel.org publikoval jeho fotografii. Jedná se o Framework Desktop s AMD Ryzen AI Max a lokální LLM.
Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
mode server dev tun0 client-config-dir ccd keepalive 10 120 port 5000 proto tcp client-to-client comp-lzo persist-key persist-tun tls-server ifconfig-pool-persist ipp.txt server 192.168.254.0 255.255.255.0 push "route 192.168.1.0 255.255.255.0" push "dhcp-option DNS 192.168.1.254" push "dhcp-option WINS 192.168.1.254" push "dhcp-option NBT 8" ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key dh /etc/openvpn/dh1024.pem log /var/log/openvpn status /var/run/openvpn/vpn.status 10ktorá funguje úplne bez problému. To znamená, že môžem pingať napríklad zo stroja 192.168.1.1 (ktorý je priamo na eth1 rozhraní napríklad na stroj 192.168.254.6 ktorý je pripojený cez VPN a naopak. Takisto keď na stroji pripojenom cez vpn (192.168.254.6) zadám do exploreru adresu \\pc1 (čo je vlastne \\192.168.1.1) tak sa bez problémov zobrazí a naopak keď dám na stroji ktorý je priamo za serverom (192.168.1.1) do exploreru adresu \\pc_mi1 (čo je vlastne 192.168.254.6) tak to opäť bez problému funguje. Ale problém nastáva keď si chcem zobraziť "Miesta v sieti". Proste na stroji 192.168.1.1 vidím iba stroje zo subnetu 192.168.1.0/24 (a samozrejme samotný server - \\router) a na stroji 192.168.254.6 vidím iba sám seba. WINS server samozrejme je nahodený a funguje - keď sa pozriem do /var/cache/samba/wins.dat tak tam vidím všetky stroje (to znamená, že tie so subnetu 192.168.1.0/24 ale aj tie z VPN). Už ma bolí hlava od googlovania a jediné rozumné čo som našiel bolo http://nbfw.sourceforge.net/ ale toto je už bohužiaľ mŕtvy projekt. Bridge s VPN použiť nemôžem, lebo vzhľadom na to, ako sa ide rozširovať sieť by bolo nedostatok IP adries a musel by som opäť robiť routing čo by ma dostalo do toho istého problému. Dúfam, že som sa vyjadril jasne a vopred veľmi pekne ďakujem za každé nakopnutie.
preferred master = auto domain master = yes local master = yesa na klientech, zvláště MS musíš mít povolenou komunikaci, resp. vypnutý FW pro TAP Win32 rozhraní. Jinak se ti v okolních počítačích, chceš-li z XP Místa v síti neuvidí. To je pro případ OpenVPN GUI 2.0.
A najdou stanice ten Win server? Zkus ho zadat natvrdo.
Já jsem podobný problém měl s notebooky připojenými přes Wi-Fi k Sambě. Např. pinknout se dalo, protože si to našlo přes DNS, ale v okolních počítačích nic nebylo ani to nešlo přidat do domény. Když jsem jim IP Win serveru vnutil na tvrdo, tak se vše rozjelo. Ono to nejspíš lze nějak zadat DHCP, aby jim to správně řeklo, ale už jsem to zatím dál neřešil.
Ještě jeden takový úplně hloupý dotaz: Zkoušel jsi to s úplně vypnutým FireWallem?
Jednou mi taky cosi nechodilo, přestože to ve FW bylo povolené a pak jsem v jakémsi hluboce zanořeném upřesnění našel, že to je povolené ale pro IP adresy, které se na tom stroji používali dřív a potom byly změněné.
interfaces = eth0,tun0, atd ...
Dale openvpn rika toto:
Routing disadvantages
* Clients must use a WINS server (such as samba) to allow cross-VPN network browsing to work.
* Routes must be set up linking each subnet.
* Software that depends on broadcasts will not "see" machines on the other side of the VPN.
* Works only with IPv4 in general, and IPv6 in cases where tun drivers on both ends of the connection support it explicitly.
Dale by ti mohlo pomoct toto:
How can I connect Windows XP to a Linux-based Samba server using routing rather than bridging? internal net: 192.168.1.0/24 samba server: 192.168.1.5 gateway 192.168.1.1 windows xp: dialup networking server config on linux gateway: dev tun0 ifconfig 192.168.5.6 192.168.5.5 <-- openvpn-net port 12345 verb 1 local 123.123.123.12 <-- official server ip adress user nobody group nogroup secret /etc/openvpn/key tun-mtu 1500 daemon open port 12345 on the firewall on server (gateway) on windows xp: Go to windows network panel. Set the windows tap-device from application control to always connected. Set the ipadress to 192.168.5.5 netmask 255.255.255.252. Leave DNS and gateway empty. openvpn config on Windows XP: dev tun0 ifconfig 192.168.5.5 192.168.5.6 <-- openvpn-net port 12345 ip-win32 manual verb 1 remote 123.123.123.12 <-- official serveripadress secret C:\programme\openvpn\config\key tun-mtu 1500 ping 30 create a batchfile: route add 192.168.1.0 mask 255.255.255.0 192.168.5.6 ping 192.168.1.5 net use g: \\192.168.1.5\Daten /USER:user1 <-- your account on samba!! After connecting to the internet, start the batch file and enter the password for samba. Viola, now you have the service Daten on drive g:. Now you can set the service openvpn to start automatically and only start the batch file after internet connection. Richard LechnerJa pouzivam taky routing (protoze je lepsi) a nemam problem mezi obema pobackami firmy, co jsou ve spolecne domene ...
Ono ta chyba nemusí být jen ve tvých konfiguracích. S tím procházením "Míst v síti" bývají občas problémy i ve Win-only sítích. Ještě prosím tě napiš, co máš na těch stanicích za systém. Je to na všech stejné nebo se to liší?
A ještě jedna úplná stupidita. Máš na tom noťasu správně nastavenou workgroupu? Pokud je jiná, tak by se to chovalo přesně tak jak tobě.
) neviem vysvetliť.
Vyzkoušej do smb.conf zadat
remote browse sync = 192.168.254.6jestli to vnutí tomu notebooku násilím.
Vyzkoušej taky
remote announce = 192.168.1.255 192.168.254.255
wins support = yesHLAVNE NE:
wins server = 1.2.3.4Jestli maka zjistis v logu ... Dalsi reseni by bylo pouzit DNS sluzbu (tak to delam ja) a nstavit v sambe:
dns proxy = yes
Toto má správně. Podívej se o pár příspěvků výš, jsou tam přiložené jeho konfiguráky.
Zkus použít TAP místo TUN pro VPN.
TUN by měl to měl simulovat na úrovni IP packetů, TAP na úrovni Ethernetových rámců.
Na VPN nejsem zrovna odborník. Ale podle toho, že nepomohlo ani to vynucení přes "remote browse sync" a "remote announce" usuzuji, že nefunguje UDP broadcast. Zkoušel jsem o tom zagooglit a v diskuzích doporučují toto.
What is the difference between bridging and routing?
Bridging and routing are two methods of linking systems via a VPN.
Bridging advantages
* Broadcasts traverse the VPN -- this allows software that depends on LAN broadcasts such as Windows NetBIOS file sharing and network neighborhood browsing to work.
* No route statements to configure.
* Works with any protocol that can function over ethernet, including IPv4, IPv6, Netware IPX, AppleTalk, etc.
* Relatively easy-to-configure solution for road warriors.
Bridging disadvantages
* Less efficient than routing, and does not scale well.
Routing advantages
* Efficiency and scalability.
* Allows better tuning of MTU for efficiency.
Routing disadvantages
* Clients must use a WINS server (such as samba) to allow cross-VPN network browsing to work.
* Routes must be set up linking each subnet.
* Software that depends on broadcasts will not "see" machines on the other side of the VPN.
* Works only with IPv4 in general, and IPv6 in cases where tun drivers on both ends of the connection support it explicitly.
What are the fundamental differences between bridging and routing in terms of configuration? When a client connects via bridging to a remote network, it is assigned an IP address that is part of the remote physical ethernet subnet and is then able to interact with other machines on the remote subnet as if it were connected locally. Bridging setups require a special OS-specific tool to bridge a physical ethernet adapter with a virtual TAP style device. On Linux, for example, brtcl is this tool. On Windows XP or higher, select your TAP-Win32 adapter and your ethernet adapter in Control Panel -> Network Connections, then right click and select Bridge Connections. When a client connects via routing, it uses its own separate subnet, and routes are set up on both the client machine and remote gateway so that data packets will seamlessly traverse the VPN. The "client" is not necessarily a single machine. It could be a subnet of several machines. Bridging and routing are functionally very similar, with the major difference being that a routed VPN will not pass IP broadcasts while a bridged VPN will. When you are bridging, you must always use --dev tap on both ends of the connection. If you are routing you can use either --dev tap or --dev tun, but you must use the same on both ends of the connection. --dev tun tends to be slightly more efficient for the routing case.
). A práve kvôly tomu som na bode mrazu. Už som hádam prekutral celý google ale neviem sa pohnúť.
ip route add multicast 255.255.255.255 dev eth1Provozuji Debian Etch.
Na tom stroji se sambou mi pripadal zbytecny ...
Proc je na tom firewallu povoleno UDP na FORWARD na tom celem rozsahu poru od 1024-65000 ??
Tiskni
Sdílej: