Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 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í. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Po více než 10 letech vývoje vyšel NetworkManager 1.0.0, sada nástrojů pro správu síťových připojení. Nejnovější verze přichází například s novou klientskou knihovnou libnm, novým DHCP klientem nebo vylepšeným nmcli.
Tiskni
Sdílej:
)
21.12.2014 12:34
the.max | skóre: 46
| blog: Smetiště
Tohle mi opravdu hodně chybí, přitom to přeci nemůže být takový problém (teď to řeším jednoduchým skriptem pro dispatcher).Jestliže to řešíš skriptem, nestálo by za to ho klukům přiložit k bugreportu? Na obě zmíněné vlastnosti si pamatuju, že byly v upstreamu tickety, takže by neměl být problém sledovat dění. Já osobně už automatické připojení VPN nevyužiju, protože se musím hlásit přes OTP, navíc ne vždycky se chci přihlašovat do VPN. Jak je to s více VPN zároveň vůbec netuším, hodně se o tom mluvilo na Freenode, ale jestli to mělo nějaké výsledky...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
21.12.2014 01:12
service openvpn restart, tj. vůbec nepoužívám NetworkManager pro připojení k VPN. To samozřejmě po nějaké aktualizaci (asi přímo NetworkManageru) taky přestalo správně fungovat, protože se NetworkManager snaží ovládat i rozhraní, která by neměl (ale jde mu to poměrně snadno zakázat).
Skript využívající pro VPN NetworkManager je na ArchWiki.No já osobně ho nepotřebuju, takže cílem nebylo abych se k němo dostal já, ale tak třeba se někomu hodit bude.
To samozřejmě po nějaké aktualizaci (asi přímo NetworkManageru) taky přestalo správně fungovat, protože se NetworkManager snaží ovládat i rozhraní, která by neměl (ale jde mu to poměrně snadno zakázat).Neznám jediného aktivního vývojáře NetworkManageru za opensuse, takže bych doporučil spíše odkazovat se na upstream, pokud to jde.
používat více VPN zároveň?
Nejhorší je, když používají stejné podsítě1. Ještě by se dalo směrovat na úrovni jednotlivých IP adres, ale když kolidují i ty, tak je to opravdu špatné. Pokud nekolidují alespoň porty2, tak by to mělo jít přes označování paketů v iptables a směrování přes pravidla ip rule. Nemáte to někdo rozchozené?
[1] nebo stačí i jedna VPN a kolize s místní podsítí
[2] např. v jedné síti se chci připojovat na 192.168.1.123:80 a přes jinou VPN na 192.168.1.123:25
21.12.2014 18:10
ip a všechno si ladím ručně přesně podle svých potřeb. Co jsem mluvil s Thomasem, tak pracoval v posledních týdnech na změnách, které značně ulehčují koexistenci takových úprav s běžícím NetworkManagerem, ale tam jsou zase jiné problémy.
BTW: nemáš nějaké tipy pro ladění? V aktuální verzi Kubuntu se přes NM nepřipojím, kolegové se starší distribucí se připojí (naklikané to bylo stejně) a z příkazové řádky, když přímo zavolám vpnc s jeho konfigurákem, tak se taky připojím.
nmcli connections a nmcli connections show UUID, jak už jsem jednou někde v diskuzi psal. Není špatné při připojování číst systémový log. Jsou i další techniky jako spustit samotný plugin z příkazové řádky (je to jen dbusem aktivovaná služba), ale chce to mít do začátku nějaké vodítko na čem to vůbec selhává a až podle toho má smysl nějak detailně ladit.
) nebo nevím... takováhle mega-bezpečnostní díra se jen tak nevidí!
Ve zkratce: pokud člověk používá samostatně OpenVPN, v kombinaci s NM to dříve fungovalo, ale od určitého updatu NM tiše přepíše defaultní routy nastavené OpenVPN na tun rozhraní. Takže traffic, který by měl běžet přes VPN, běží přímo nešifrovaně do Internetu aniž by se to člověk dozvěděl (pokud zrovna člověk nestuduje logy nebo ručně nekontroluje routy a/nebo externí IP adresu). Vsadím se že obrovská spousta lidí se na tohle chování spoléhala a toho updatu co způsobil tuhle tichou změnu chování si ani (minimálně nějakou dobu) nevšimla a mohli na to i pěkně narazit/doplatit...
ale to že vývojáři nevydali opravný release a někdy od října až do teď teď tam tahle mega bezpečnostní díra tiše zůstávala považuji za naprosto tristní!Fakt jsem zvědavý na CVE a na security bugy v upstreamu i distribucích. Zatím žádné nevidím.
Fakt nechápu uvažování lidí okolo NM...Já mám to štěstí (nebo smůlu), že ho obecně docela chápu, jsem s těmi lidmi pořád čas od času v kontaktu ;). Ale ke konkrétnímu případu, posuzování a řešení security bugů je v první řadě důležitou úlohou distribucí, takže pokud to za security bug nepovažují distribuce, těžko to vyčítat upstreamovému projektu.
Na druhou stranu je někdy dost komplikované identifikovat, zda jde o problém distribučních balíčků nebo o problém upstreamového vývoje.To je věc, které se teď snažím trochu věnovat, když už nejsem v core vývoji. Jedna z věcí, do kterých jsem se pustil je podpora appindicator, která je nezbytná pro provoz nm-applet v prostředích jako je Enlightenment, Unity a KDE. V případě KDE to není až tak zajímavé, ti mají vlastní GUI stejně jako Gnome 3, ale Enlightenment před pár týdny vyhodil už tak špatnou podporu pro Xembed systray a ubunťáci si v každém releasu aplikovali vlastní značně zprasené patche, které musejí vždy znovu adaptovat. Další je úprava podpory session managerů jako je logind nebo consolekit do té míry, aby šel NetworkManager kompilovat s podporou obojího a k výběru došlo až za běhu. Když zbyde čas, tak prolézám zdrojáky distribučních balíků, abych viděl, co používají za patche. To jsou drobnosti, na které core vývojáři jen těžko hledají čas a energii.
NetworkManager se mi jako idea líbí, ale jakmile člověk chce trošku lepší konfiguraci sítě (bonding eth s wlan na notebooku, VPN, atp.)Myslím, že jsem to před časem zkoušel (s vlastním patchem), pokud bych usoudil, že to chci používat, tak se na to ještě někdy podívám, ale zatím mám problém to pořádně zautomatizovat, vzhledem k tomu, že bych chtěl bonding a eth používat jen s konkrétní wifi sítí, kterou používám s konkrétní eth sítí a tím pádem se můžu vůbec postarat o to, aby to celé fungovalo. On to není ani tak složitější setup jako nestandardní setup. Osobně jsem si zvyknul, že většina software je průser, pokud si je nemůžu sám opatchovat a proto jsem nedávno po dlouhé době opět přešel na Gentoo.
Btw. to ani nezmiňuju tenhle bug, který snad do NetworkManageru vnesl nějaký agent NSA (či snad MPAAMůžu znát číslo CVE nebo odkaz na nějaké informace o nahlášení? Pokud se nikdo s CVE neobtěžoval, tak asi bez komentáře.
Ve zkratce: pokud člověk používá samostatně OpenVPN, v kombinaci s NM to dříve fungovalo, ale od určitého updatu NM tiše přepíše defaultní routy nastavené OpenVPN na tun rozhraní.Tak to tě můžu uklidnit, že přepisování informací od jiných nástrojů dílem NSA není. Takto NetworkManager fungoval vždycky, jenom neuměl tolik typů rozhraní. To, že si přivlastní úplně každé rozhraní je tím pádem něco jako vedlejší efekt nově přidané funkcionality za poslední rok až dva. Co mě ale sere je, že si NetworkManager přivlastňuje úplně všechna rozhraní a není vůbec jednoduché mu domluvit, aby to nedělal. Když jsem na core věcech v NetworkManageru ještě pracoval, tak jsem připravil sadu patchů, která zajišťovala, že si NetworkManager bude umět převzít rozhraní, která má spravovat (na základě toho, že pro něj existuje konfigurace dostatečně odpovídající té skutečné) a tím pádem by nikdy nespravoval rozhraní, pro které vůbec žádnou konfiguraci nemá nebo kde se konfigurace zásadně liší od toho, co tam najde. Bohužel kluci před aplikováním sadu patchů ještě upravili a rozhodli se, že se budou spravovat všechna rozhraní, akorát některá nebudou měnit. Už mi několikrát vysvětlovali, jak je to super, že se zbaví
STATE_UNMANAGED. To by bylo všechno krásné, kdyby se ho nezbavovali bez náhrady. Hlavně jsem je několikrát žádal, abych přes nmcli alespoň viděl informaci o tom, zda NetworkManager bude rozhraní měnit nebo nebude.
Nahlásil jsem na to bug v březnu. V den zadání se mi od jednoho kolegy (stále jsem v RH, že) dostalo vskutku duchaplného příspěvku. V listopadu jsem podrobněji objasňoval, kde je v té jejich krásné myšlence díra. Ani to se nesetkalo s pochopením.
Pak tam přibyla hromada odkazů na RH bugzillu a začalo se něco dít a dneska je to označeno jako vyřešené. Současné chování jsem netestoval, používám NetworkManager z Gitu s vlastními patchi, protože se mi prakticky nic, co jsem potřeboval, nepodařilo do 1.0 dostat, ať už proto, že jsem se o plánovaném vydání dozvěděl na poslední chvíli, měl jsem dost vlastní práce, nebo se to zdrželo na straně upstreamu.
21.12.2014 12:40
the.max | skóre: 46
| blog: Smetiště
ip route prozradí vše. Pokud vím, tak Thomas Haller na routovacích prioritách zrovna pracoval. Nevím jistě, zda jsou finální výsledky práce součástí 1.0, ale předpokládám, že ano, bavili jsme se o tom asi týden před vydáním. Na problému přinejmenším spolupracují NM a kernel ;).