Accolta parechji VHosts cù diversi utilizatori in Nginx

A cosa più nurmale in u mondu quandu avete un servitore, hè di pensà à a sicurezza è à più sicurezza, ùn si pò mai esse abbastanza paranoici

Una pratica un pocu cumuna è NENI raccomandata, hè di aduprà u listessu utilizatore per tutte e basi di dati, peghju se si usa a radice, chì per incredibile quant'è pò sembrà, ci sò quelli chì (per via di vagabondità o ignuranza) Fate questu, aghju digià parlatu perchè ùn duvete micca agisce cusì in altra postAvà hè ora di spiegà cumu è perchè hè megliu à separà a trasfurmazione di u servore web in diversi utilizatori, sta volta serà aduprendu Nginx.

DedicatedServer_SubImage

Chì ghjè quellu di l'utilizatori è u servitore web?

Per spiegà in una manera breve è simplice, u servitore web (apache, nginx, qualunque cosa) hà bisognu di apre processi in u sistema, prucessi chì saranu quelli chì piglianu i fugliali da u HDD (immagini, ecc.) È li facenu dispunibule per u navigatore di u cliente. U servore web ùn pò micca simpliciamente piglià i fugliali è manipulalli chì ùn sò nimu, vale à dì, hà bisognu di un utilizatore chì serà quellu chì farà tuttu què à a fine, è quellu utilizatore hè quellu di quale parlu, capite?

Chì ghjè quellu di separà in parechji utilizatori?

Supponemu chì in u nostru servitore avemu 2 siti web, u nostru chì hè un prugettu persunale, è un altru (imaginemu chì hè a nostra amica o fratellu). Ancu quandu usamu basi di dati separati è utilizatori diversi per accede à elli, à a fine i fugliali di i dui siti web sò manipulati da u listessu utilizatore, u trattamentu PHP hè gestitu da u listessu utilizatore per tutti i siti (di solitu www-data). Questa hè una pratica micca raccomandata, hè megliu avè tuttu ben separatu, cum'è dice un vechju dettu, hè megliu esse sicuru ch'è scusatu.

Ok capiscu, cumu facciu cù Nginx

2000px-Nginx_logo.svg

A prima cosa da nutà hè chì Nginx ùn hà micca u so propiu modulu chì gestisce l'elaborazione di PHP cum'è Apache, per Nginx avemu bisognu di aduprà PHP-CGI o PHP-FPM, chì funziona cusì bè (o megliu) chè Apache. Cusì per separà l'elaborazione PHP trà diversi utilizatori, averemu bisognu di cambià e linee in i fugliali di cunfigurazione PHP (CGI o FPM), micca Nginx stessu.

Eppo suppone chì utilizate PHP-FPM, creeremu un schedariu di cunfigurazione di piscina Per un situ specificu, vale à dì, una piscina hè u modu per separà l'elaborazione PHP da PHP-FPM, ma andemu in parte.

1. Prima ci vole à sapè quale utilizatore di u sistema utteremu, presumiremu chì ùn avemu ancu micca creati è bè, creemu:

Tutti i seguenti cumandamenti DEVONU esse eseguiti cù privilegi amministrativi, sia cù radice diretta sia cù sudo

adduser blog

Iniziaremu u prucessu normale di creazione di un utilizatore, inserite a password, ecc.

Bloggu l'utilizatore solu per seguità l'esempiu, chì u primu situ chì ospiteremu serà un blog, bè chì ... per cunnosce ogni utilizatore cù quale situ hè in relazione

1. Prima andemu in /etc/php5/fpm/pool.d/:

cd /etc/php5/fpm/pool.d/

2. Avà, creeremu un schedariu chjamatu blog.conf:

touch blog.conf

3. Avà metteremu a cunfigurazione di a piscina chì useremu per u blog VHost:

Edite u fugliale blog.conf cù nano ... per esempiu: sudo nano blog.conf
[bloggu] utilizatore = bloggu
gruppu = bloggu
listen = / var / run / php5-fpm-bloggu.sock listen.owner = bloggu
ascolta.gruppu = bloggu
pm = ondemand pm.max_children = 96 chdir = /

Nutate bè: Ciò chì li marcu in rossu hè ciò ch'elli devenu mudificà secondu l'usu chì anu creatu prima. Per esempiu, se creanu un altru VHost cù un altru utilizatore (foru per esempiu) allora invece di u blog mette solu u foru in ognuna di e linee, hè capitu?

4. Una volta a cunfigurazione di u novu gruppu (u fugliale blog.conf chì avemu appena creatu è editatu), hè u turnu di dì à Nginx VHost di aduprà un calzettu diversu per quellu VHost, per stu situ. U calzettu chì serà utilizatu serà quellu chì avemu dichjaratu prima (/var/run/php5-fpm-blog.sock). Editemu u Nginx VHost è in a parte di trasfurmazione PHP, indicemu di aduprà quessi calzini. Per esempiu:

situazione ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-bloggu.calzino;
include fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Cumu pudete vede, indicu chì u processu PHP di quellu VHost (quelle linee sò per esempiu in / etc / nginx / sites-enabled / vhost-blog) Falla cù i calzini truvati in /var/run/php5-fpm-blog.sock ... chì hè quellu chì avemu creatu prima quandu editemu /etc/php5/fpm/pool.d/blog.conf ... hè ùn hà micca capitu?

5. Una volta fattu questu, ripartimu i dui servizii (php5-fpm è nginx) è voilà, videremu chì a trasfurmazione di quellu situ (vhost) ùn hè micca fatta da www-data o root o qualcunu simile, ma da l'utente chì definitu prima.

Quì vi mostru u risultatu di a ps aux | grep fpm nantu à unu di i servitori di u mo node:

ps aux | grep fpm ebook 586 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool ebook ebook 589 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool ebook www 608 0.0 0.2 350084 5008? S Mar30 0:00 php-fpm: piscina www www 609 0.0 0.2 350600 5048 30? S Mar0 00:3 php-fpm: piscina www tv611 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: piscina tv3 tv615 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: piscina tv1818 rivista 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: rivista rivista piscina 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: piscina rivista pupulare 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: rivista di pupilla di piscina 1.8 1.7 437764 36152 10? S 22:0 18:2754 php-fpm: pool gutl magazine 3.5 1.3 356724 27164 10? S 38:0 00:5624 php-fpm: piscina gutl cgr 0.0 1.0 365168 22696 28? S Apr0 16:7900 php-fpm: piscina cgr pupilla 0.3 2.5 457052 52444 25? S Apr20 23:11021 php-fpm: pupilla pupilla pupilla 0.4 2.5 458316 52864 28? S Apr5 57:11254 php-fpm: piscina pupilla cgr 0.0 1.0 363152 21708 28? S Apr0 12:13184 php-fpm: piscina cgr cgr 0.0 1.0 362872 21360 28? S Apr0 08:XNUMX php-fpm: piscina cgr

Cumu pudete vede ... separà u processu PHP da l'utilizatori chì utilizanu Nginx + PHP-FPM hè veramente faciule, allora vedete chì ci sò parechje piscine, chì ci sò parechji utilizatori.

CONCLUSIONES

Quandu si tratta di servitori, ùn site mai abbastanza paranoicu ... a sicurezza ùn hè micca qualcosa da ghjucà, più pruvemu sempre à migliurà a sicurezza di i nostri servitori è di i so servizii, menu seremu spaventati da un (successu) tentativu di pirate o qualcosa di simile 😉


U cuntenutu di l'articulu aderisce à i nostri principii di etica edituriale. Per signalà un errore cliccate quì.

9 cumenti, lasciate i toi

Lasciate u vostru cummentariu

U vostru indirizzu email ùn esse publicatu. campi, nicissarii sò marcati cù *

*

*

  1. Responsabile di i dati: Miguel Ángel Gatón
  2. Scopu di i dati: Cuntrolla SPAM, gestione di cumenti.
  3. Legitimazione: U vostru accunsentu
  4. Cumunicazione di i dati: I dati ùn seranu micca cumunicati à terzi, eccettu per obbligazione legale.
  5. Archiviazione di dati: Base di dati ospitata da Occentus Networks (UE)
  6. Diritti: In ogni mumentu pudete limità, recuperà è cancellà e vostre informazioni.

  1.   cacciatore dijo

    Gaara, in i tempi attuali queste cose devenu esse automatizate quant'è pussibule, vi ricumandemu di pruvà Ansible. Senza agente, avete bisognu solu di pitone nantu à l'ospitu remotu, assai simplice di cunfigurà, i fugliali yaml, mudelli Jinja.

    https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx

    1.    KZKG ^ Gaara dijo

      Fighjemu, ùn hè micca sempre solu per i siti WordPress, è ... haha ​​forse Ansible clicca volao, ma preferiscu sapè esattamente cumu tuttu funziona nantu à u servitore, ancu se devu passà 1 minutu à creà un novu calzini è un novu VHost 😀

      1.    cacciatore dijo

        Cù Ansible automatizate tuttu, fate praticamente ciò chì vulete, u vantaghju di stu metudu hè chì incapsulate a pratica è poi eseguite à piacè, imaginate chì avete un situ assai caricu è chì vulete fà bilanciamentu di carica trà i servitori d'applicazione, questi duvete esse cunfiguratu esattamente listessu ùn pudete micca saltà un passu o fà qualcosa di diversu in unu di elli, vi puderete immaginà di fà a procedura passo per passu 4 volte? Cù Ansible hè simplice cum'è aghjunghje u nome di l'ostendariu à u fugliale di inventariu è Voilá !!

        http://www.ansible.com/how-ansible-works

      2.    cacciatore dijo

        Scusate per u cultu Ansible, ma hè una di sti tecnulugie chì scopre è vulete chì tutti l'utilizanu avà perchè hè cusì cool è praticu, hè cum'è quandu scopri NGINX è vulete chì tutti i vostri amichi abbanduninu Apache immediatamente.

        https://speakerdeck.com/slok/ansible-all-the-things

  2.   Mstaaravin dijo
  3.   Rots87 dijo

    Sò (o studiu per esse) sviluppatore è cù NGIX aghju avutu assai prublemi quandu cunfigurava nginx + php-fpm. Sò chì a distro di archlinux ùn hè micca u megliu per falla cum'è servitore, ma ogni volta chì aghju aggiornatu una versione di ngix o php tuttu hè sempre andatu allora aghju rinunziatu à u tentativu lol ... Per oghje sò statu cù u classicu Apache + PHP ma Videraghju se circondu NGIX di novu ... forse in una macchina virtuale

    1.    cacciatore dijo

      A mentalità cambia un pocu, nginx serve u cuntenutu staticu è serve da proxy inversu per u php-fpm chì hè quellu chì gestisce u veru PHP, duvete principià in parte è andà à uttene u dispiegamentu passu à passu, cercate una guida per schjattà u quadru chì travaglia, ognunu hà u so dettagliu cù i nomi di u publicu, staticu, risorse, ecc ...

  4.   anònimu dijo

    Fate à a cumunità u grande favore di abbandunà a parolla "hostear", chì ùn esiste micca. Per Diu, hè cusì difficiule à dì "ostia"?

  5.   Wil dijo

    Saluti, seguitendu u vostru esempiu, vogliu sapè se una piscina puderia esse fatta solu per u wordpress backen, vale à dì per u wp-admin facendu un novu socket per e cunnessioni entranti à u backend

    location / wp-admin {
    root /var/www/yoursite.com/wp-admin;
    index.php index.html index.htm;
    locu ~ ^ / wp-admin /(.+. php) $ {
    pruvà_files $ uri = 404;
    root /var/www/yoursite.com/wp-admin;
    include / etc / nginx / fastcgi_params;

    fastcgi_pass server unix:/run/php5-fpm2.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 256 4k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_read_timeout 1240;
    }
    location ~* ^/wp-admin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
    root /var/www/tusitio.com/wp-admin/;
    }
    }