Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
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ě:
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/html
Ví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?
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
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
To budu asi ja ;)
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?