Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
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.
Mám síť s několika počítači a jedním routerem, na všem běží SuSE Linux 8.1, kromě routeru, tam je Devil-Linux 0.5 (distribuce CD + FDD bez HDD). Nakonfiguroval jsem takové ty běžné věci jako iptables, dns, dhcp server a podobně - vše na routeru s Devil-Linuxem. Vše funguje tak jak má. Připojení k internetu jsem dosud simuloval počítačem s věřejnou ip adresou a přístup skrze router-firewall je z vnitřní sítě (192.168.x.x) normální dle představ, resolvování jmen i IP adres funguje, IP adresy jsou korektně přidělovány atd...
Mám ale problém s ssh, po jedné z úprav, a bohužel nevím které, protože jich v ten okamžik bylo víc, začal mít neuvěřitelně dlouhé odezvy. Místo přihlášení (authentikuju se rsa klíčem) během tak dvou - tří sekund (i dříve, počítače jsou Pentia 4 na 1,7GHz) se najednou authentikace protáhla až na desítky sekund, v některých případech jsem naměřil i více než minutu a takovou odezvu nezaznamenávám ani při připojování přes telefonní linku na mnohonásobně pomalejší počítač.
Znovu jsem prověřil všechno možné, síť - myšleno hardware, pravidla iptables, dns a prostě vše co by mohlo dělat problémy a co mne napadlo. Nakonec jsem zjistil, že ssh se zasekne vždy na dvou bodech a to:
1/ debug1: SSH2_MSG_KEXINIT sent
2/ debug1: SSH2_MSG_KEXINIT sent
Obojí trvá zhruba stejně dlouho, ačkoliv jinde proběhne okamžitě. Nepovedlo se mi vygooglovat nic použitelného. Tušíte čím by to mohlo být?
debug1: SSH2_MSG_KEXINIT sent --- tady? --- debug1: SSH2_MSG_KEXINIT received(tvoje 1/ a 2/ je stejné ;) vzhledem k tomu, že to trvá tak dlouho, neměl by být problém podívat se, co ten počítač během toho dělá. ať už lokálně, nebo s čím během toho komunikuje (tcpdump, ethereal, ...), podle délky odezvy mi to připadá, jako kdyby se snažil někam connectnout (ale to je divné, protože mi není jasné kam, reverse mapping by měl snad failnout rychle, když už)
David Nečas & ostatní: Ad body 1 a 2, ten druhý bod mělo být toto:
debug1: next auth method to try is gssapi
kokot: - Nastavení ssh deamona i klienta je defaultní.
Beda: - Nakonec se ukázalo, že pravděpodobně vytimeoutuje DNS, takže zakazování na firewallu by moc nepomohlo, resp. asi ano, ale nebylo by to použitelné v reálném provozu. Krom toho, firewall na běžných portech vrací unreachable místo aby packet jen zahodil.
Všem díky za snahu.
Všichni: - Problém se mi nakonec vyřešit povedlo. Tcpdumpem jsem zjistil, že se přihlašující se počítač snaží spojit s jedním z mých servisních počítačů, kterých se to vůbec týkat nemělo. Konkrétně s počítačem pojmenovaným kerberos, který představoval v tu chvíli internet, tj. měl veřejnou IP adresu a byl připojen na vnější straně firewallu.
Tenhle počítač kerberos, ale měl v DNS a DHCP záznam. Tj. měl podle MAC adresy správně dostat pevnou IP podle záznamu v DNS a ta měla být privátní, shodou okolností ve stejném segmentu, jako se nachází počítač, kterému to tak dlouho trvalo.
Závada zmizela poté, co jsem odstranil záznam z konfigurace DHCP serveru a z DNS. Poté se přihlašující se počítač přestal odkazovat na kerberose úplně. Takže teď vše funguje tak jak má.
Přiznávám, že ale nechápu, proč vůbec byl odesílán jakýkoliv požadavek na třetí počítač.
Tomáš Konir: - Authentikuju se RSA klíčem, ale fakt je, že už mne taky napadlo jestli hostname kerberos nedělá problémy. Nevím.
Tiskni Sdílej: