Byla vydána verze 8.18 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Projekty Blink a Blinkenlights dospěly do verze 1.0. Jedná se o x86-64-linux emulátor a jeho TUI nadstavbu sloužící jako debugger. Blink je v porovnání s qemu-x86_64 menší a rychlejší.
Bylo potvrzeno, že Debian 12 s kódovým jménem Bookworm vyjde v tuto sobotu 10. června.
Byla vydána nová verze 2023.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení. Zdůraznit lze předpřipravené obrazy pro Hyper-V nebo to, že ve výchozím prostředí Xfce bylo PulseAudio nahrazeno multimediálním serverem PipeWire.
Tento týden byla vydána nová verze 1.52 webového prohlížeče Brave (Wikipedie, GitHub). Postavena je na Chromiu 114. Z novinek lze vypíchnout možnost povolit vertikální karty (vertical tabs). Také bylo představeno Brave Search API k vyhledávači Brave Search.
Matthias Clasen z Red Hatu oznámil v diskusním listu vývojářů Fedora Linuxu, že tým Red Hat Display Systems se zaměří na Wayland a podporu HDR na Linuxu a přestane spravovat RPM balíčky pro LibreOffice. V další major verzi RHELu už LibreOffice nebude. Pokud se nenajde správce balíčků pro Fedora Linux, zůstane pouze LibreOffice ve Flatpaku.
Na Steamu lze získat zdarma počítačovou hru Tell Me Why (ProtonDB). Na Epic Games Storu počítačovou hru Midnight Ghost Hunt (ProtonDB).
Společnost Meta představila (YouTube) brýle pro virtuální realitu Meta Quest 3. V prodeji budou na podzim a stát budou od 499,99 dolarů.
Byla vydána nová verze 2.41.0 distribuovaného systému správy verzí Git. Přispělo 95 vývojářů, z toho 29 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Organizace Apache Software Foundation (ASF) vydala verzi 18 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
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: