Fedora je od 10. února dostupná v Sýrii. Sýrie vypadla ze seznamu embargovaných zemí a Fedora Infrastructure Team mohl odblokovat syrské IP adresy.
Ministerstvo zahraničí Spojených států amerických vyvíjí online portál Freedom.gov, který umožní nejenom uživatelům v Evropě přístup k obsahu blokovanému jejich vládami. Portál bude patrně obsahovat VPN funkci maskující uživatelský provoz tak, aby se jevil jako pocházející z USA. Projekt měl být původně představen již na letošní Mnichovské bezpečnostní konferenci, ale jeho spuštění bylo odloženo.
Byla vydána pro lidi zdarma ke stažení kniha The Book of Remind věnovaná sofistikovanému kalendáři a připomínači Remind.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.5.0. Oznámení připomíná 30. výročí vzniku projektu. Novinky zahrnují mj. vylepšení referencí nebo použití barev napříč aplikací, od rozhraní editoru po výstupní dokument.
F-Droid bannerem na svých stránkách a také v aplikacích F-Droid a F-Droid Basic upozorňuje na iniciativu Keep Android Open. Od září 2026 bude Android vyžadovat, aby všechny aplikace byly registrovány ověřenými vývojáři, aby mohly být nainstalovány na certifikovaných zařízeních Android. To ohrožuje alternativní obchody s aplikacemi jako F-Droid a možnost instalace aplikací mimo oficiální obchod (sideloading).
Svobodná historická realtimová strategie 0 A.D. (Wikipedie) byla vydána ve verzi 28 (0.28.0). Její kódový název je Boiorix. Představení novinek v poznámkách k vydání. Ke stažení také na Flathubu a Snapcraftu.
Multimediální server a user space API PipeWire (Wikipedie) poskytující PulseAudio, JACK, ALSA a GStreamer rozhraní byl vydán ve verzi 1.6.0 (Bluesky). Přehled novinek na GitLabu.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.2 a 20.04 OTA-12.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
Dobrej. Nevite nekdo, proc mi Apache2 vypisuje tyhle chyby?
[warn] Init: SSL server IP/port conflict: webdav.mojedomena.cz:443 (/etc/apache2/sites-enabled/webdav.mojedomena.cz:3) vs. webmail.mojedomena.cz:443 (/etc/apache2/sites-enabled/webmail.mojedomena.cz:27)
[warn] Init: SSL server IP/port conflict: fax.mojedomena.cz:443 (/etc/apache2/sites-enabled/fax.mojedomena.cz:3) vs. webmail.mojedomena.cz:443 (/etc/apache2/sites-enabled/webmail.mojedomena.cz:27)
[warn] Init: SSL server IP/port conflict: drupal.mojedomena.cz:443 (/etc/apache2/sites-enabled/001drupal.mojedomena.cz_redirect:3) vs. webmail.mojedomena.cz:443 (/etc/apache2/sites-enabled/webmail.mojedomena.cz:27)
[Mon Feb 16 23:13:59 2009] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
------>>>> certifikaty mam vytvorene pro *.mojedomena.cz
Navrhované řešení není nejlepší a taktéž staví na zastaralém předpokladu, že každý virtuální TLS server musí mít vlastní IP adresu.
V podstatě existují dvě řešení:
Předpokládejme, že klient i server umí TLS. Pro každý virtuální server si vytvoříte vlastní certifikát na jeho jméno v commonName a když se připojí klient, tak při vyjednávání TLS pošle ve zprávě HELO jméno požadovaného serveru, podle ní server vybere certifikát a ten vrátí klientovi.
Předpokládejme, že klient podporuje RFC 2818. Pak si vyrobíte certifikát, který v commonName bude mít „Toto je Frantův server“ a v rozšíření subjectAltName vyjmenujete všechna doménová jména v záznamech typu dNSName. Klient je pak povinnen nezajímat se commonName (to slouží pro lidi) a musí prozkoumat všechny dNSName záznamy.
Předpokládejme, že klient i server umí TLS.Např. MSIE 6, který má stále asi 20% podíl, neumí.
Ano, presne tuhle hlasku jsem hledal a nasel jsem vzdy odpoved, ze toto Apache2 pise v pripade, ze mam pro jednu IP vice certifikatu pro ruzne virtualhosty. Reseni vsude bylo takove, udelat certifikat s CN *.mojedomena.cz (coz jsem mel a mam) a problem se s tim vyresi... bohuzel si Apache2 i presto stezuje..
mam pro jednu IP vice certifikatu pro ruzne virtualhostyTo "pro jednu IP adresu" vynechte, problém je v tom, že používáte SSL certifikáty pro name-based virtual hosty. Alespoň to je napsané v té hlášce. Jestli Apache podporuje hvězdičkové certifikáty nebo vícenásobné subjekty, musíte jej nakonfigurovat s touto podporou.
A kde nastavim, aby Apache2 podporoval hvezdickove certifikaty. Z pozice klienta mam pocit, ze je podporuje, protoze prohlizec nekrici, ze server je jineho jmena nez certifikat...
Wildcart je ten "hvezdickovy" jestli to dobre chapu.. Zatim jsem se nesetkal s tim, ze by s tim mel nejaky klient problem.. Ale nechapu, proc s tim ma problem Apache2 (alespon podle toho logu)...
Ja mam Virtualhosty zalozene na IP adrese, respektive od nove verze Apache2 (v Lenny) je to promenna, ktera odkazuje na IP adresu zapsanou v /etc/apache2/envvars ..
No a jsme zase u toho, k čemu jsou tedy ty "hvezdickove" certifikaty, ktere se bezne pouzivaji?
To chapu. Ja mam jeden kus zeleza, jednu IP a virtualhosty s tou jednou IP. Apache2 by mel byt podle me spokojeny, ale neni .... no nechame to, kdybych si nevsiml te chyby, tak mam pocit, ze vse funguje tak jak ma..
Ja mam ... jednu IP a virtualhosty s tou jednou IP.A to je problem. Nemozes mat virtualhosty s jednou IP -- t.j. name-based -- a zaroven pouzivat SSL. Pri prijati requestu je potrebne na zaklade niecoho rozhodnut, ktory z virtual hostov ma request obsluzit. Pri name-based sa rozhoduje na zaklade polozky protokolu HTTP/1.1 Host: v hlavicke requestu. Tato je ale v momente prijatia requestu cez SSL spojenie sifrovana, t.j. necitatelna. Na rozsifrovanie treba najskor urcit, ktory z virtualhostov ju ma rozsifrovat. Preto sa o pouzitom virtualhoste rozhoduje na zaklade niecoho ineho, co je mimo sifrovanych udajov. V tomto pripade na zaklade IP adresy, na ktoru request dorazil. Preto je pre SSL potrebne pouzitie IP-based virtualhostingu.
Nemozes mat virtualhosty s jednou IP -- t.j. name-based -- a zaroven pouzivat SSL.
Tiskni
Sdílej: