Wine bylo po roce vývoje od vydání verze 9.0 vydáno v nové stabilní verzi 10.0. Přehled novinek na GitLabu. Vypíchnuta je nová architektura ARM64EC a podpora High DPI škálování.
Edvard Rejthar na blogu zaměstnanců CZ.NIC představil nástroj deduplidog pro odstranění duplicitních souborů.
Společnost DeepSeek představila (𝕏) AI model DeepSeek-R1 (Hugging Face) srovnatelný s OpenAI o1 a uvolnila jej pod open source licencí MIT, tj. zdarma i pro komerční použití.
GKrellM (GNU Krell Monitors, Wikipedie), tj. grafická aplikace pro sledování systémů a různých událostí, byla po pěti a půl letech vydána v nové verzi 2.4.0. Přehled novinek na Gitea.
Americká první dáma Melania Trumpová vydala v předvečer manželovy inaugurace vlastní kryptoměnu. Jmenuje se $Melania. Donald Trump vydal vlastní kryptoměnu $Trump den před manželkou.
GNU Project Debugger aneb GDB byl vydán ve verzi 16.1. Podrobný přehled novinek v souboru NEWS.
Po 9 týdnech vývoje od vydání Linuxu 6.12 oznámil Linus Torvalds vydání Linuxu 6.13. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies. Odstraněn byl souborový systém ReiserFS.
19. ledna 2038 přeteče hodnota time_t na 32bitových systémech, na vyřešení problému roku 2038 (Y2K38) tedy zbývá 13 let. Např. Debian v uplynulém roce přešel na 64bitový čas. Bernhard Wiedemann z openSUSE sdílí chyby v sestavení rozšířeného softwaru.
Byla vydána druhá opravná verze 21.2 v dubnu loňského roku vydané verze 21 multimediálního centra Kodi (dříve XBMC, Wikipedie) s kódovým označením Omega.
TikTok ve Spojených státech v sobotu večer místního času přerušil činnost. Uživatelé čínskou firmou vlastněné sociální sítě dostali zprávu, že aplikaci kvůli zákazu nelze používat. TikTok je momentálně nedostupný v obchodech s aplikacemi Google Play a App Store. Podle zákona přijatého loni a potvrzeného v pátek soudem měla platforma do dneška přerušit spojení se svou mateřskou společností ByteDance, která sídlí v Číně, nebo činnost v
… více »http://front.dom.cz --> http://back.dom.cz:8080/app1V adresním řádku prohlížeče se má zobrazovat http://front.dom.cz/app1 To už jsem s pomocí zdejší poradny zvládnul: na front.dom.cz inkluduju do httpd.conf soubor mod_proxy.conf s tímto obsahem
ProxyRequests Off ProxyPreserveHost On <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /app1 http://back.dom.cz:8080/app1 ProxyPassReverse /app1 http://back.dom.cz:8080/app1 ProxyPass / http://back.dom.cz:8080/app1 ProxyPassReverse / http://back.dom.cz:8080/app1Schéma HTTPS
https://front.dom.cz --> https://back.dom.cz:8443/app1Zobrazovat se má
https://front.dom.cz/app1Popravdě, potřebuju šifrované spojení HTTPS jen pro přihlašování, ale to bych zatím neřešil. Klidně ať zatím běží celá aplikace na HTTPS, před přihlášením i po. To je ostatně věc aplikace. Na frontendu jsem zapnul SSL v Apache a definoval virtuálního hosta /etc/apache2/vhosts.d/front.dom.cz
<IfDefine SSL> <IfDefine !NOSSL> NameVirtualHost IPadresaFront:443 <VirtualHost IPadresaFront:443> DocumentRoot "/srv/www/htdocs/front.dom.cz" ServerName IPadresaFront:443 ServerAdmin admin@dom.cz ErrorLog /var/log/apache2/error_log TransferLog /var/log/apache2/access_log SSLEngine on SSLProtocol all -SSLv2 SSLCipherSuite HIGH:MEDIUM SSLCertificateFile /etc/apache2/ssl.crt/ap2server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/ap2server.key SSLCertificateChainFile /etc/apache2/ssl.crt/newca.crt SSLCACertificateFile /etc/apache2/ssl.crt/newca.crt <Files ~ "\.(cgi|shtml|phtml|php3?)$"> SSLOptions +StdEnvVars </Files> <Directory "/srv/www/htdocs/front.dom.cz"> Options Indexes AllowOverride None Allow from from all Order allow,deny </Directory> CustomLog /var/log/apache2/ssl_request_log ssl_combined </VirtualHost> </IfDefine> </IfDefine>Ačkoli jsem na backendovém stroji SSL ještě nezprovoznil a proxy pro HTTPS nenastavil, funguje mi https://front.dom.cz/app1, tj. zobrazuje obsah z back.dom.cz/app1, ale jestli šifrovaně, to nepoznám. Zdá se, že direktivy z mod_proxy.conf mi přesměrovávají i HTTPS provoz. Ale to nejspíš nebude v pořádku, když SSL je jen na proxy serveru, že? Rád bych, aby byla celá komunikace šifrovaná, nejen se tak tvářila. Kde všude má být konfigurováno SSL a vložen certifikát? Potřebuju certifikát s Common Name=front.dom.cz. Jak korektně nastavit proxy pro HTTPS provoz? Díkes za každou radu!
https
, je komunikace šifrovaná. V případě HTTPS bude šifrovaná komunikace vždy mezi klientem a proxy serverem, ten musí šifrovanou komunikaci vybalit, a pak s ní něco udělá dál. Pokud je Tomcat na stejném stroji nebo ve stejné důvěryhodné síti, je zbytečné komunikaci znovu šifrovat a je lepší mezi proxy a Tomcatem použít obyčejné HTTP. Certifikát a vše týkající se HTTPS pak bude jen na Apachi. Ještě můžete (snad) nastavit proxy tak, že bude Tomcatu v hlavičkách předávat informaci o tom, že komunikace byla šifrovaná, pak to lze i z Tomcatu ze servletu zjistit voláním ServletRequest.isSecure()
.
Část konfiguráku mi připadá zbytečná, nebo tam opravdu máte nějaké PHP nebo CGI skripty?
<Files ~ "\.(cgi|shtml|phtml|php3?)$"> SSLOptions +StdEnvVars </Files>Jinak máte nějaký důvod, proč tam cpát ten proxy server? Bude na tom portu 80 a 443 poskytovat ještě nějaké jiné služby? Jinak můžete vystavit do internetu rovnou Tomcat a bude to celé jednodušší...
Díky za radu. Ano, server s Tomcatem (backend) leží v důvěryhodné síti, takže komunikace Proxy - Tomcat nemusí být šifrovaná. Nebyl jsem si jist, zda HTTPS komunikace nutně musí být end-to-end, tedy z klienta až k backendovému serveru, nebo stačí, když bude šifrovaná jen část, která jde k frontendu. Proto tedy použiju obyčejné HTTP.
Část toho konfiguráku je opravdu zbytečná, půjde pryč.
Proxy je tam kvůli snížení zátěže na server s Tomcatem, a časem z něho taky bude load balancer - backendových serverů přibyde.
Nebyl jsem si jist, zda HTTPS komunikace nutně musí být end-to-end, tedy z klienta až k backendovému serveru, nebo stačí, když bude šifrovaná jen část, která jde k frontendu.Naopak, HTTPS je vždy mezi klientem a serverem/proxy, kde je dané HTTPS spojení zakončeno. Tam se musí dešifrovat, ověřit certifikáty atd., a případně je možné odsud navázat další spojení (HTTP i HTTPS), kterým se přenese dešifrovaný obsah spojení. Nejsnazší je vždy si uvědomit, že HTTPS chrání proti útokům MITM -- takže uprostřed komunikace nemůže být nikdo, kdo by s komunikací nějak manipuloval nebo ji mohl číst.
http://front.dom.cz
) směrovala na http://back1.dom.cz/app1
a HTTPS (https://front.dom.cz
) aby směrovala na http://back2.dom.cz/app1
.
Vytvořil jsem dva virtual hosty s touto konfigurací:
front.dom.cz.conf
NameVirtualHost 10.0.0.1:80 <VirtualHost 10.0.0.1:80> ServerName 10.0.0.1 ServerAdmin admin@dom.cz ProxyRequests Off ProxyPreserveHost On <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /app1 http://back1.dom.cz:8080/app1 ProxyPassReverse /app1 http://back1.dom.cz:8080/app1 ProxyPass / http://back1.dom.cz:8080/app1 ProxyPassReverse / http://back1.dom.cz:8080/app1 DocumentRoot /srv/www/vhosts/front.dom.cz ErrorLog /var/log/apache2/front.dom.cz-error_log CustomLog /var/log/apache2/front.dom.cz-access_log combined #HostnameLookups Off #UseCanonicalName Off #ServerSignature On <Directory "/srv/www/vhosts/front.dom.cz"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> </VirtualHost>
front.dom.cz_ssl.conf
<IfDefine SSL> <IfDefine !NOSSL> <VirtualHost 10.0.0.1:443> ServerName 10.0.0.1:443 ServerAdmin adminn@dom.cz ProxyRequests Off ProxyPreserveHost On <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass /app1 http://back2.dom.cz:8080/app1 ProxyPassReverse /app1 http://back2.dom.cz:8080/app1 ProxyPass / http://back2.dom.cz:8080/app1 ProxyPassReverse / http://back2.dom.cz:8080/app1 DocumentRoot "/srv/www/vhosts/front.dom.cz_ssl" ErrorLog /var/log/apache2/front.dom.cz_ssl-error_log TransferLog /var/log/apache2/front.dom.cz_ssl-access_log CustomLog /var/log/apache2/front.dom.cz_ssl-request_log ssl_combined <Directory "/srv/www/vhosts/front.dom.cz_ssl"> Options Indexes AllowOverride None Allow from from all Order allow,deny </Directory> SSLEngine on SSLProtocol all -SSLv2 SSLCipherSuite HIGH:MEDIUM SSLCertificateFile /etc/apache2/ssl.crt/ap2server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/ap2server.key SSLCertificateChainFile /etc/apache2/ssl.crt/newca.crt SSLCACertificateFile /etc/apache2/ssl.crt/newca.crt </VirtualHost> </IfDefine> </IfDefine>Při startu Apache si mi webový server stěžuje
... Starting httpd2 (prefork) [Thu Mar 29 12:32:28 2012] [warn] worker http://back1.nkp.cz:8080/app1 already used by another worker [Thu Mar 29 12:32:28 2012] [warn] worker http://back2.nkp.cz:8080/app1 already used by another worker Apache/2.2.12 mod_ssl/2.2.12 (Pass Phrase Dialog) ...Na webu jsem našel, že se to stává, když je nějaká proxy direktiva zadaná vícekrát. Ale já tam nemám nic, co by se opakovalo... Nebo mám? Když v prvním konfiguráku zakomentuju řádky
ProxyPass / http://back1.dom.cz:8080/app1 ProxyPassReverse / http://back1.dom.cz:8080/app1tak si Apache už nestěžuje, ale pak zas nefunguje přesměrování
http://front.dom.cz
na http://back1.dom.cz/app1
Nemám tušení, proč mu to vadí. Je to vlastnost Apache, nebo moje chyba?
/app1
ProxyPass /app1 http://back1.dom.cz:8080/app1 ProxyPassReverse /app1 http://back1.dom.cz:8080/app1
Tiskni Sdílej: