Gastigu multajn VHosts kun malsamaj uzantoj en Nginx

La plej normala afero en la mondo, kiam vi havas servilon, estas pensi pri sekureco kaj pli da sekureco, vi neniam povas esti sufiĉe paranoja 😉

Iom ofta praktiko kaj NENION rekomendinda estas uzi la saman uzanton por ĉiuj datumbazoj, pli malbone se oni uzas radikon, kiu kiel ajn nekredebla ŝajnas, estas tiuj, kiuj (pro vagado aŭ nescio) faru ĉi tion, mi jam parolis pri kial vi NE agu tiel en alia afiŝoNun estas tempo por klarigi kiel kaj kial estas pli bone disigi la prilaboradon de retservilo en diversaj uzantoj, ĉi-foje ĝi uzos Nginx.

Dediĉa Servilo_Subbildo

Kio estas tio de uzantoj kaj retservilo?

Por klarigi ĝin en simpla kaj mallonga maniero, la retservilo (apache, nginx, kio ajn) bezonas malfermi procezojn en la sistemo, procezojn, kiuj estos tiuj, kiuj prenas la dosierojn de la HDD (bildoj, ktp.) Kaj faras ilin havebla al la retumilo de la kliento. La retservilo ne povas simple preni la dosierojn kaj manipuli ilin estante neniu, tio estas, ĝi bezonas uzanton, kiu finfine faros ĉion ĉi, kaj tiu uzanto estas tiu, pri kiu mi parolas, ĉu vi komprenas?

Kio estas disiĝi ĉe pluraj uzantoj?

Ni supozu, ke en nia servilo ni havas 2 retejojn, la nia, kiu estas persona projekto, kaj alia (ni imagu, ke ĝi estas nia koramikino aŭ frato). Eĉ kiam ni uzas apartajn datumbazojn kaj malsamajn uzantojn por aliri ilin, finfine la dosieroj de ambaŭ retejoj estas manipulitaj de la sama uzanto, la PHP-prilaborado estas administrata de la sama uzanto por ĉiuj retejoj (kutime www-datumoj). Ĉi tio estas malrekomendinda praktiko, estas pli bone ĉion bone disigi, kiel diras malnova diro, estas pli bone esti sekura ol bedaŭrinda.

Bone mi komprenas, kiel mi faras ĝin kun Nginx

2000px-Nginx_logo.svg

La unua afero rimarkinda estas, ke Nginx ne havas propran modulon, kiu traktas PHP-prilaboradon kiel Apache, por Nginx ni bezonas uzi PHP-CGI aŭ PHP-FPM, kiu funkcias tiel bone (aŭ pli bone) ol Apache. Do, por apartigi la PHP-prilaboradon en diversaj uzantoj, ni bezonos ŝanĝi liniojn en agordaj dosieroj de PHP (CGI aŭ FPM), ne Nginx mem.

Supozu, ke vi uzas PHP-FPM, ni kreos agordan dosieron de naĝejo por specifa retejo, tio estas, komunkaso estas la maniero apartigi PHP-prilaboradon de PHP-FPM, sed ni iras en partoj.

1. Unue ni devas scii kiun uzanton de la sistemo ni uzos, mi supozos, ke ni ankoraŭ havas neniun kreitan kaj nu, ni kreu ĝin:

Ĉiuj jenaj komandoj DEVAS esti plenumitaj per administraj privilegioj, ĉu per rekta radiko aŭ per sudo

adduser blog

Ni komencos la normalan procezon krei uzanton, enigi la pasvorton, ktp.

Mi blogas la uzanton nur por sekvi la ekzemplon, ke la unua retejo, kiun ni gastigos, estos blogo, nu ke ... scii ĉiun uzanton kun kiu retejo rilatas

1. Unue ni iru al /etc/php5/fpm/pool.d/:

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

2. Nun ni kreos dosieron nomatan blog.conf:

touch blog.conf

3. Nun ni metos la agordon de la komunkaso, kiun ni uzos por la blogo VHost:

Redaktu la dosieron blog.conf per nano ... ekzemple: sudo nano blog.conf
[blogo] uzanto = blogo
grupo = blogo
aŭskultu = / var / run / php5-fpm-blogo.sock aŭskultu.posedanto = blogo
aŭskultu.grupo = blogo
pm = ondemand pm.max_children = 96 chdir = /

Noto: Mi markas ilin ruĝe, kion ili devas modifi laŭ la uzanto, kiun ili antaŭe kreis. Ekzemple, se ili kreas alian VHost kun alia uzanto (forumo ekzemple) tiam anstataŭ blogo simple metu forumon en ĉiun el la linioj, ĉu oni komprenas?

4. Iam la agordo de la nova grupo (la dosieron blog.conf, kiun ni ĵus kreis kaj redaktis), estas la vico diri al la Nginx VHost uzi alian ŝtrumpeton por tiu VHost, por ĉi tiu retejo. La ŝtrumpeto uzota estos tiu, kiun ni antaŭe deklaris (/var/run/php5-fpm-blog.sock). Ni redaktu la Nginx VHost kaj en la prilaborada parto de PHP, ni indikas uzi tiujn ŝtrumpetojn. Ekzemple:

loko ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unikso: / var / run / php5-fpm-blogo.ŝtrumpeto;
inkluzivi fastcgi_params; fastcgi_param SCRIPT_FILENAME $ dokumenta_radiko $ fastcgi_script_name; fastcgi_read_timeout 300; }

Kiel vi vidas, mi indikas, ke la PHP-prilaborado de tiu VHost (tiuj linioj estas ekzemple en / etc / nginx / sites-enabled / vhost-blog) faru ĝin per la ŝtrumpetoj trovitaj en /var/run/php5-fpm-blog.sock ... kiu estas tiu, kiun ni kreis antaŭe redaktante /etc/php5/fpm/pool.d/blog.conf ... estas ĝi komprenis ne?

5. Post kiam ĉi tio estas farita, ni rekomencas ambaŭ servojn (php5-fpm kaj nginx) kaj voila, ni vidos, ke la prilaborado de tiu retejo (vhost) NE estas farita de www-data aŭ root aŭ iu ajn simila, sed de la uzanto, ke ni antaŭe difinita.

Jen mi montras al vi la rezulton de a ps aux | grep fpm sur unu el la serviloj de mia nodo:

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: naĝejo www www 609 0.0 0.2 350600 5048 30? S Mar0 00:3 php-fpm: naĝejo www tv611 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: naĝejo tv3 tv615 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: naĝejo tv1818 revuo 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: revuo por naĝejo 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: naĝejo revuo lernanto 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: naĝejo pupilo 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: pool gutl cgr 0.0 1.0 365168 22696 28? S Apr0 16:7900 php-fpm: naĝejo cgr lernanto 0.3 2.5 457052 52444 25? S Apr20 23:11021 php-fpm: naĝejo lernanto lernanto 0.4 2.5 458316 52864 28? S Apr5 57:11254 php-fpm: naĝa lernanto cgr 0.0 1.0 363152 21708 28? S Apr0 12:13184 php-fpm: pool cgr cgr 0.0 1.0 362872 21360 28? S Apr0 08:XNUMX php-fpm: pool cgr

Kiel vi povas vidi ... disigi la PHP-prilaboradon de uzantoj per Nginx + PHP-FPM estas vere facila, tie vi vidas, ke ekzistas pluraj grupoj, ĉar estas pluraj uzantoj.

Konkludoj

Se temas pri serviloj, vi neniam estas sufiĉe paranoja ... sekureco ne estas io por ludi, des pli ni ĉiam provas plibonigi la sekurecon de niaj serviloj kaj iliaj servoj, des malpli verŝajne ni timos (sukcesa) haka provo aŭ io simila 😉


La enhavo de la artikolo aliĝas al niaj principoj de redakcia etiko. Por raporti eraron alklaku Ĉi tie.

9 komentoj, lasu la viajn

Lasu vian komenton

Via retpoŝta adreso ne estos eldonita. Postulita kampojn estas markita per *

*

*

  1. Respondeculo pri la datumoj: Miguel Ángel Gatón
  2. Celo de la datumoj: Kontrola SPAM, administrado de komentoj.
  3. Legitimado: Via konsento
  4. Komunikado de la datumoj: La datumoj ne estos komunikitaj al triaj krom per laŭleĝa devo.
  5. Stokado de datumoj: Datumbazo gastigita de Occentus Networks (EU)
  6. Rajtoj: Iam ajn vi povas limigi, retrovi kaj forigi viajn informojn.

  1.   ĉasisto diris

    Gaara, nuntempe ĉi tiuj aferoj devas esti aŭtomatigitaj laŭeble, mi rekomendas al vi provi Ansible. Sen agento, vi bezonas nur python en la fora gastiganto, tre facile agordi, yaml-dosierojn, ŝablonojn Jinja.

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

    1.    KZKG ^ Gaara diris

      Ni vidu, tio ne ĉiam estas nur por WordPress-ejoj, kaj ... haha ​​eble Ansible klakas volao, sed mi preferas scii precize kiel ĉio funkcias en la servilo, eĉ se mi devas pasigi 1 minuton kreante novajn ŝtrumpetojn kaj nova VHost 😀

      1.    ĉasisto diris

        Kun Ansible vi aŭtomatigas ĉion, vi faras praktike ĉion, kion vi volas, la avantaĝo de ĉi tiu metodo estas, ke vi enkapsuligas la praktikon kaj tiam plenumas laŭplaĉe, imagu, ke vi havas tre ŝarĝitan retejon kaj vi volas fari ŝarĝan ekvilibrigon inter aplikaĵaj serviloj, ĉi tiuj devas esti ĝuste agordita, vi ne povas salti paŝon aŭ fari ion alian en unu el ili, ĉu vi povas imagi fari la proceduron paŝon post paŝo 4 fojojn? Kun Ansible estas tiel simple kiel aldoni la gastigantan nomon al la inventara dosiero kaj Voilá !!

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

      2.    ĉasisto diris

        Pardonu pri la Ansible-kulto, sed ĝi estas unu el ĉi tiuj teknologioj, kiujn vi malkovras kaj vi volas, ke ĉiuj uzu ĝin nun, ĉar ĝi estas tiel mojosa kaj praktika, kiel kiam vi malkovras NGINX kaj vi volas, ke ĉiuj viaj amikoj forlasu Apache tuj.

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

  2.   Mstaaravin diris
  3.   Putras87 diris

    Mi estas (aŭ studas esti) programisto kaj kun NGIX mi havis multajn problemojn dum agordo de nginx + php-fpm. Mi scias, ke la arklinua distro ne estas la plej bona por krei ĝin kiel servilo, sed ĉiufoje kiam mi ĝisdatigis version de ngix aŭ php ĉio ĉiam fiaskis, do mi rezignis la provon lol ... Por hodiaŭ mi restis kun la klasika Apache + PHP sed Mi vidos, ĉu mi ĉirkaŭiros NGIX denove ... eble per virtuala maŝino

    1.    ĉasisto diris

      La pensmaniero iom ŝanĝiĝas, nginx servas la statikan enhavon kaj funkcias kiel inversa prokurilo por la php-fpm, kiu administras la veran PHP, vi devas komenci per partoj kaj realigi la deplojon paŝon post paŝo, serĉi gvidilon por disfaldi la kadro kun kiu vi laboras, ĉiu havas sian detalon laŭ la nomoj de publiko, statika, rimedoj, ktp ...

  4.   anonima diris

    Ĉu la komunumo havas la grandan favoron forlasi la vorton "hostear", kiu ne ekzistas. Je Dio, ĉu estas tiel malfacile diri "gastiganto"?

  5.   Wil diris

    Salutojn, sekvante vian ekzemplon, mi ŝatus scii ĉu kombinaĵo povus esti farita nur por la wordpress backen, tio estas, por ke la wp-administranto kreis novan inkon por alvenantaj ligoj al la backend

    loko / wp-administranto {
    root /var/www/yoursite.com/wp-admin;
    indekso index.php index.html index.htm;
    loko ~ ^ / wp-admin /(.+. php) $ {
    provu_dosierojn $ uri = 404;
    root /var/www/yoursite.com/wp-admin;
    inkluzivi / 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/;
    }
    }