VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
nginx (vyslovováno engine x) je lehkotonážní webový server/reverzní proxy vydaný pod licencí BSD. Mimo protokolů http/http(s) zvládá i POP3 a IMAP, takže se ve skutečnosti nejedná jen o webový server. Ale na e-mailové vlastnosti tohoto webového serveru se v článku zaměřovat nebudeme.
Tento webový server umí servírovat veškerý statický obsah (statické HTML, CSS, iso, ...) a určitý typ požadavků směřovat jinam. Nativně webserver neumí PHP, ani Python, Ruby, ... je to jen "hloupá proxy" a webový server pro statický obsah. Avšak důležité je to, že je to i proxy. Pokud si totiž jako pomocníka přivoláme buď FastCGI, nebo jiný webový server (který už mod_php nebo cokoli jiného, po čem toužíme, umí), můžeme nginx použít jako proxy pro servírování tohoto obsahu.
Na svém serveru ism.m4r3k.org používám FastCGI PHP s nginxem. FastCGI PHP je zhruba stejně rychlé jako mod_php, avšak nese sebou větší paměťový overhead, což však u méně náročných webových prezentací nemusí vůbec vadit. Moje konfigurace vypadá následovně:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
user nginx;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
gzip on;
server {
listen [::]:80;
server_name ism.m4r3k.org;
location / {
root /srv/www/htdocs/ism.m4r3k.org/;
index index.html index.htm index.php;
}
# redirect server error pages to the static page /50x.html
error_page 500 502 503 504 50x.html;
location = /50x.html {
root /srv/www/htdocs/ism.m4r3k.org/;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /srv/www/htdocs/ism.m4r3k.org/$fastcgi_script_name;
include fastcgi_params;
}
}
}
První řádek user říká nginxu, aby po svém startu zahodil rootovská privilegia a začal fungovat pod uživatelem nginx. Start pod uživatelem root je nutný, pokud chcete, aby nginx běžel na portech nižších než 1024, které si může nabindovat jen root.
Řádek worker_processes říká, kolik má běžet procesů pro obsluhu uživatelských požadavků. Každý worker proces může obsloužit takový počet příchozích spojení, jaký je definován konfiguračním řádkem worker_connections. Důvodem pro zvýšení počtu worker procesů může být například využití více jader/procesorů u serveru s SMP, případně snížení latence způsobené blokacemi z I/O. Pokud si chcete spočítat maximální počet spojení, které je v jednu chvíli váš server schopen obsloužit, docílíte toho tím, že vynásobíte počet worker procesů hodnotou worker spojení (worker_processes * worker_connections), v naší konfiguraci je tedy webový server schopen obsloužit maximálně 1024 klientů.
V části konfigurace http načítáme soubor mime.types, který obsahuje přiřazení Content-Type k jednotlivým příponám souborů.
types {
text/html html htm shtml;
text/css css;
text/xml xml;
image/gif gif;
image/jpeg jpeg jpg;
application/x-javascript js;
application/atom+xml atom;
application/rss+xml rss;
}
Parametr gzip udává, zda se budou odchozí soubory komprimovat gzipem, nebo ne. V případě zapnuté gzip komprese můžete konfigurační soubor rozšířit o volby:
text/htmlVíce konfiguračních voleb pro modul gzip najdete v dokumentaci.
Sekce http má podsekci server, ve které už se konfigurují jednotliví virtuální hosté.
Řádek listen [::]:80; určuje, na jakých adresách a portech má nginx nabindovat svůj socket. Uvedená konfigurace nabidnuje nginx na port 80 na všechny IPv4 a IPv6 adresy; parametr listen může obsahovat adresu, na kterou se má server nabindovat, případně port.
127.0.0.1 - nabinduje nginx na adresu 127.0.0.1 port 80127.0.0.1:8080 - nabinduje nginx na adresu 127.0.0.1 port 8080443 default ssl - nabinduje nginx na všech IPv4 adresách na port 443 pro https spojeníKonfigurační volba server_name se používá pro named virtual hosty. Z každého příchozího HTTP požadavku se vezme hlavička Host a ta je pak porovnávána se server_name. Při první shodě je požadavek obsloužen podle dané konfigurace. Volba server_name může být klasické jméno ism.m4r3k.org, jméno se žolíkovým znakem (wildcard) na začátku či konci (*.ism.m4r3k.org, ism.m4r3k.*) nebo jméno definované regulárním výrazem. server_name může mít více záznamů, v takovém případě se jednotlivé záznamy oddělují mezerou.
První část location obsahuje pokyny, jak obsloužit všechny HTTP požadavky, volba root určuje cestu k adresáři, kde jsou k nalezení požadovaná data. Na rozdíl od webového serveru Apache nginx nezahazuje matchující se část v location. Budete li tedy chtít mít pro adresář /tmp/ povoleno procházení (autoindexing), musíte vytvořit následující location.
location /tmp/ {
root /srv/www/htdocs/ism.m4r3k.org/;
autoindex on;
}
Tato část konfiguračního souboru zajistí, že každý požadavek http://ism.m4r3k.org/tmp/nejaky-soubor.txt bude směřovat do adresáře /srv/www/htdocs/ism.m4r3k.org/tmp/. A pokud se někdo pokusí otevřít http://ism.m4r3k.org/tmp/, tak se mu zobrazí všechny soubory včetně podadresářů, vizte například tuto stránku.
Konfigurační volba error_page slouží k nastavení chování chybových kódů HTTP protokolů. Uvedený řádek error_page 500 502 503 504 50x.html; zajistí, aby byly uvedené chybové kódy 500, 502, 503, 504 přesměrovány na statickou stránku 50x.html. Úplně stejně můžete pracovat i s dalšími kódy jako 404 Not found nebo 403 Forbiden. Případně můžete také zajistit změnu chybového kódu, například pokud místo kódu 404 Not found chcete vracet nějaký soubor s kódem 200 OK, můžete do konfiguračního souboru přidat následující řádek error_page 404 =200 vraceny-soubor.html;.
Jak jsem již řekl, nginx neumí mod_php, jako to dělá Apache, ale umí FastCGI, což je na většinu použití dostatečné. A pokud FastCGI nestačí, může nám na pozadí běžet Apache a nginx dělat k tomuto webserveru jen proxy. O FastCGI PHP se nám stará poslední část uvedeného konfiguračního souboru, tedy ta začínající location ~ \.php$. Znak ~ označuje regulární výraz, který slouží k identifikaci požadavků, jež mají být zpracovávány pomocí FastCGI. Volba fastcgi_pass specifikuje, kam má nginx předávat své požadavky na zpracování. Může se jednat o IP adresu a port jako v mém případě nebo o Unixový socket - zadáte unix:/cesta-k/socketu.socket. Řádek fastcgi_index index.php; říká, jaké má být jméno zpracovávaného souboru, pokud bude uvedená cesta končit znakem lomítka (/). V našem případě se jedná o FastCGI PHP, takže očekáváme v adresáři soubor index.php. Další řádek je fastcgi_param. Ten slouží k nastavování parametrů pro CGI požadavek, který bude odeslán na cíl podle volby fastcgi_pass. V našem příkladu nastavujeme volbu SCRIPT_FILENAME na cestu k samotnémi CGI skriptu, tedy /srv/www/htdocs/prace.m4r3k.org/$fastcgi_script_name. Jak jistě uhádnete, proměnná $fastcgi_script_name obsahuje všechno, co následuje po / v požadavku GET, který webserver obdržel. Pokud tedy bude požadavek GET vypadat takto: GET /scripts/rss.php HTTP/1.1, tak v proměnné $fastcgi_script_name bude cesta scripts/rss.php.
Posledním řádkem načítám soubor /etc/nginx/fastcgi_params, který obsahuje následující parametry pro FastCGI:
fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name;
Nyní, když jsme donutili nginx předávat požadavky na php soubory někam dále, slušelo by se ještě zajistit, aby tyto požadavky i očekávalo něco, co je následně zpracuje - jinak dostaneme chybovou zprávu 502 Bad gateway. Já osobně jsem se inspiroval tím, jak to dělá lighttpd, a použil jsem program spawn-fcgi k tomu, aby mi vytvořil požadovaný počet procesů php-cgi, nabindoval jim sockety a zahodil rootovská privilegia. spawn-fcgi spouštím s následujícími parametry:
/usr/bin/spawn-fcgi -C 10 -a 127.0.0.1 -p 9000 -u nginx -f /usr/bin/php-cgi
Parametr -C udává počet instancí, které mají být spuštěny, -a je adresa, na kterou se má php-cgi nabindovat, -p udává port, na který se bude bindovat, -u udává uživatele, pod kterým se má php-cgi spouštět, a -f udává cestu k binárce, která se má spouštět.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Ve chvílích, kdy Apache přestává stíhatTo mi v této oblasti přijde už jako klišé. Apache toho zvládne docela hodně, záleží na konfiguraci, přičemž konfigurace "jeden Apache dělá všechno" není zrovna z nejvýkonnějších. Ale je pravda, že servery jako nginx nebo Lighttpd mají nároky (prostředky OS, CPU i paměť) ještě menší a hlavně mají i jednodušší (nebo prostě jen hezčí) konfiguraci.
je to jen "hloupá proxy"Ehm, jak vypadá chytrá proxy? Je mi jasné, že pokud něco neumí out-of-the-box nativně PHP, spousta PHP programátorů to bude považovat za nepotřebný balast a proto je třeba je poučit, ale zacházet až tak daleko
Důvodem pro zvýšení počtu worker procesů může být například využití více jader/procesorů u serveru s SMP, případně snížení latence způsobené blokacemi z I/O.Myšleno je nejspíš diskové I/O, že... Blokující síťové I/O, to by si snad při single-process single-thread architektuře nikdo nedovolil... Vlastně když už jsme u té architektury, jaký že je to ten hlavní rozdíl mezi nginxem a Apachem a proč narozdíl od Apache můžeme s klidným svědomím nechat worker_processes na hodnotě 1?
A rozdíl by tu byl ještě jeden
To mi v této oblasti přijde už jako klišé. Apache toho zvládne docela hodně, záleží na konfiguraci, přičemž konfigurace "jeden Apache dělá všechno" není zrovna z nejvýkonnějších. Ale je pravda, že servery jako nginx nebo Lighttpd mají nároky (prostředky OS, CPU i paměť) ještě menší a hlavně mají i jednodušší (nebo prostě jen hezčí) konfiguraci.Vim o mistech kde apache nestihal a nginx se flaka
Vlastně když už jsme u té architektury, jaký že je to ten hlavní rozdíl mezi nginxem a Apachem a proč narozdíl od Apache můžeme s klidným svědomím nechat worker_processes na hodnotě 1?epoll/poll/select/rtsignals...
>> A rozdíl by tu byl ještě jeden
Nesmíte věřit všemu co se kde píše. Tyhle věci se dají nastavovat a zpravidla jsou nastaveny správně, aby se podobné věci neděly.
Myšleno je nejspíš diskové I/O, že...Ano, mysleli jsme samozřejmě diskové I/O.
bez .htaccess nepouzitelne 
5.8.2009 12:37
Jendа | skóre: 78
| blog: Jenda
| JO70FB
5.8.2009 13:13
Limoto | skóre: 32
| blog: Limotův blog
Ale je nekompatibilní s Apache. Stejně jako v lighttpd...
btw pryc jsou doby kdy na nginx byla potreba rustina :)
aktualni anglicka wikina je uz velice schopna a vseobjimajici
5.8.2009 12:15
Fluttershy, yay! | skóre: 92
| blog:
To budu asi ja ;)
5.8.2009 15:53
Fluttershy, yay! | skóre: 92
| blog:
5.8.2009 15:56
Fluttershy, yay! | skóre: 92
| blog:
Chybi mi aspon strucne zduvodneni, proc by jsem mel zkusit nginx a ne treba lighttpd (ktery je znamejsi). V cem je nginx lespi nez lighttpd?
Nebo teba boa ?
Ci jine valstni napsane web servery ?
Uznavam ze apache2 je na lecktere veci tezsi ...
... ale neni to spis o konfiguraci ?
A proc BOA??
23 Feb 2005 - Version 0.94.14rc21 released!
ten projekt prakticky skoncil... Jak jej muzete porovnavat s lighttpd?
Boa je tak trochu legenda, je to webserver s pollovací architekturou snad už od roku 1995. Pamatuju si, že na přednášce o sítích na FELu, když se mluvilo o pollování, říkali tomu "ve stylu Boa".
A nějaký vlastní webserver... o tom snad ani nemá cenu mluvit
5.8.2009 07:52