Mala škola Linuxa

Ciljevi lekcije Nakon ove lekcije trebalo bi da: ograničiš pristup po IP adresi i kombinuješ to sa lozinkom postaviš ograničenje brzine zahteva bez blokiranja legitimnih korisnika razumeš burst i nodelay parametre, jer se najčešće pogrešno podese povežeš nginx sa fail2ban-om znaš koje od ovih mera prestaju da rade iza CDN-a i zašto 1. Ograničavanje po IP adresi location /admin/ { allow 192.0.2.0/24; allow 10.0.0.0/8; allow 127.0.0.1; deny all; proxy_pass http://backend; } Pravila se proveravaju odozgo naniže i prvo poklapanje pobeđuje . Zato deny all uvek ide poslednji — da je na vrhu, blokirao bi sve. Ista logika radi i u server i u http kontekstu, uz podsetnik na nasleđivanje iz lekcije 3. Kritično: iza proxy-ja ovo ne radi Ako je ispred nginx-a CDN, load balancer ili bilo koji drugi posrednik, $remote_addr je adresa tog posrednika , ne korisnika. Tvoje allow pravilo tada ili propušta sve, ili blokira sve — u zavisnosti od toga da li si sluč...

Ciljevi lekcije Nakon ove lekcije trebalo bi da: napišeš format loga koji sadrži ono što ti stvarno treba pri dijagnostici razumeš nivoe grešaka i šta se pojavljuje na kojem podesiš rotaciju i znaš zašto nginx mora da bude obavešten o njoj izvučeš korisne podatke iz loga bez posebnih alata anonimizuješ IP adrese kada to treba 1. Dva loga Access log beleži svaki zahtev. Piše se nakon što je odgovor poslat. Error log beleži probleme — od kritičnih grešaka do informativnih poruka, zavisno od podešenog nivoa. Kada nešto ne radi, ovde gledaš prvo. Podrazumevane putanje na Ubuntu-u su /var/log/nginx/access.log i /var/log/nginx/error.log . U lekciji 4 smo ih razdvojili po sajtovima — to je praksa koje se drži. 2. Formati access loga Podrazumevani format zove se combined : log_format combined '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" ...

Ciljevi lekcije Nakon ove lekcije trebalo bi da: podesiš gzip kompresiju bez trošenja procesora na sadržaj koji se ne isplati kompresovati razumeš odnos expires zaglavlja i strategije imenovanja fajlova postaviš proxy_cache i pratiš njegovu efikasnost serviraš stari sadržaj kada backend padne, umesto da vraćaš grešku rešiš pitanje invalidacije keša u besplatnoj verziji nginx-a 1. gzip kompresija Tekstualni sadržaj se kompresuje na oko četvrtinu veličine. Za HTML, CSS, JavaScript i JSON to je najjeftinije poboljšanje performansi koje postoji. http { gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 5; gzip_min_length 256; gzip_types text/plain text/css text/xml text/javascript application/javascript application/json application/xml application/rss+xml application/atom+xml image/svg+xml font/ttf font/otf; } Objašnjenja za ono što nije očigledno: ...

Ciljevi lekcije Nakon ove lekcije trebalo bi da: povežeš nginx sa PHP-FPM-om preko FastCGI protokola, i to bezbedno postaviš Python aplikaciju iza Gunicorn-a ili uWSGI-ja pustiš Node.js aplikaciju u produkciju iza reverse proxy-ja napišeš systemd unit koji drži aplikaciju živom rešiš probleme sa dozvolama nad socket fajlovima 1. Tri načina komunikacije nginx ne izvršava aplikacioni kod. On saobraća sa zasebnim procesom, na jedan od tri načina: Protokol Direktiva Tipično za FastCGI fastcgi_pass PHP-FPM HTTP proxy_pass Node.js, Gunicorn, Puma, Kestrel uWSGI uwsgi_pass Python preko uWSGI servera Izbor ne zavisi od jezika nego od toga šta aplikacioni server govori. Gunicorn govori HTTP, pa se ka njemu ide proxy_pass -om iako je Python. uWSGI govori sopstveni binarni protokol, pa ide uwsgi_pass -om. Sve tri postavke dele isti obrazac: klijent → nginx → [socket ili TCP port] → aplikacioni proces ↑ statika ide odavde, sa diska S...

Ciljevi lekcije Nakon ove lekcije trebalo bi da: izdaš i automatski obnavljaš Let's Encrypt sertifikat napišeš ispravnu TLS konfiguraciju ručno, ne samo kroz certbot podesiš preusmeravanje sa HTTP-a na HTTPS bez petlji razumeš HSTS i rizike koje nosi testiraš postavku alatima umesto da pretpostavljaš da radi 1. Šta ti treba Za HTTPS su potrebne tri stvari: privatni ključ, sertifikat koji potvrđuje da ključ pripada tvom domenu, i konfiguracija koja ih spaja. Sertifikate izdaju sertifikaciona tela (CA). Let's Encrypt ih izdaje besplatno i automatizovano, pa je danas podrazumevani izbor za ogromnu većinu sajtova. Komercijalne CA imaju smisla samo kada ti treba nešto što Let's Encrypt ne nudi — OV/EV validacija, sertifikati sa dužim rokom, ili garancija. Preduslov: domen mora da pokazuje na tvoj server pre nego što pokušaš izdavanje. Let's Encrypt proverava vlasništvo tako što traži da mu odgovoriš na tom domenu. Ako DNS nije podešen, ništa neće raditi. dig ...

Ciljevi lekcije Nakon ove lekcije trebalo bi da: definišeš grupu backend servera kroz upstream blok biraš metod raspodele prema prirodi aplikacije podesiš keep-alive konekcije prema backend-u i znaš zašto je to obavezno razumeš pasivne provere zdravlja i njihova ograničenja u besplatnoj verziji rešiš pitanje sesija kada aplikacija nije bezstanjna 1. upstream blok Umesto jedne adrese u proxy_pass , definišeš imenovanu grupu: upstream aplikacija { server 10.0.1.10:3000; server 10.0.1.11:3000; server 10.0.1.12:3000; } server { listen 80; server_name example.com; location / { proxy_pass http://aplikacija; include proxy_params; } } upstream ide u http kontekst, van server blokova. Ime grupe je proizvoljno i koristiš ga u proxy_pass na mestu gde bi inače stajao host. Isti mehanizam radi i sa unix socket-ima, što je korisno kada više instanci aplikacije radi na istoj mašini: upstream aplikacija { server unix:/run/app-1.soc...