Gostite več VHostov z različnimi uporabniki v Nginxu

Najbolj običajna stvar na svetu, ko imate strežnik, je razmišljati o varnosti in več varnosti, nikoli ne morete biti dovolj paranoični

Nekoliko pogosta praksa in NIČ, kar se priporoča, je uporaba istega uporabnika za vse zbirke podatkov, še huje, če se uporablja root, kar pa se zdi neverjetno, vendar obstajajo tisti, ki (zaradi potepuškega ali nevednega) naredi to, že sem govoril o tem, zakaj se NE smeš tako obnašati drugo objavoZdaj je čas, da razložimo, kako in zakaj je bolje ločiti obdelavo spletnega strežnika pri različnih uporabnikih, ki jih bo tokrat uporabil Nginx.

DedicatedServer_SubImage

Kaj je to pri uporabnikih in spletnem strežniku?

Za kratko in preprosto razlago mora spletni strežnik (apache, nginx, karkoli) odpreti procese v sistemu, procese, ki bodo tisti, ki bodo datoteke prevzeli s trdega diska (slike itd.) In jih naredili na voljo brskalniku stranke. Spletni strežnik ne more preprosto vzeti datotek in z njimi manipulirati kot nihče, torej potrebuje uporabnika, ki bo na koncu vse to naredil, in ta uporabnik je tisti, o katerem govorim, razumete?

Kaj je ločevanje pri več uporabnikih?

Predpostavimo, da imamo na našem strežniku dve spletni strani, našo, ki je osebni projekt, in drugo (predstavljajmo si, da je to naše dekle ali brat). Tudi ko za dostop do njih uporabljamo ločene zbirke podatkov in različne uporabnike, na koncu datoteke obeh spletnih mest manipulira isti uporabnik, obdelavo PHP za vse strani upravlja isti uporabnik (navadno gre za www-data). To je odsvetovana praksa, bolje je, da je vse dobro ločeno, kot pravi stari pregovor, je bolje biti varen kot žal.

Ok, razumem, kako naj to storim z Nginxom

2000px-Nginx_logo.svg

Najprej je treba omeniti, da Nginx nima lastnega modula, ki bi obdeloval PHP obdelavo kot Apache, za Nginx moramo uporabiti PHP-CGI ali PHP-FPM, ki deluje enako dobro (ali bolje) kot Apache. Torej, da bomo PHP obdelavo ločili med različnimi uporabniki, bomo morali spremeniti vrstice v konfiguracijskih datotekah PHP (CGI ali FPM) in ne v samem Nginxu.

Recimo, da uporabljate PHP-FPM, ustvarili bomo konfiguracijsko datoteko bazen Za določeno spletno mesto, to je bazen, je način, kako ločiti obdelavo PHP od PHP-FPM, vendar gremo po delih.

1. Najprej moramo vedeti, katerega uporabnika sistema bomo uporabili, domnevam, da še vedno nimamo nobenega ustvarjenega in dobro, ustvariva ga:

Vsi naslednji ukazi se MORAJO izvajati s skrbniškimi pravicami, bodisi z neposrednim korenom bodisi z uporabo sudo

adduser blog

Začeli bomo z običajnim postopkom ustvarjanja uporabnika, vnesli geslo itd.

Uporabnika pišem v spletni dnevnik samo zato, da sledim zgledu, da bo prvo spletno mesto, ki ga bomo gostili, blog, torej ... da bi vedel vsakega uporabnika, s katerim spletnim mestom je povezan

1. Najprej pojdimo na /etc/php5/fpm/pool.d/:

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

2. Zdaj bomo ustvarili datoteko z imenom blog.conf:

touch blog.conf

3. Zdaj bomo postavili konfiguracijo bazena, ki jo bomo uporabili za blog VHost:

Uredite datoteko blog.conf z nano ... na primer: sudo nanoblog.conf
[blog] uporabnik = blog
skupina = blog
poslušaj = / var / run / php5-fpm-blog.nogavica poslušaj.lastnik = blog
poslušaj.grupa = blog
pm = ondemand pm.max_children = 96 chdir = /

Opomba: Rdeče jih označim, kar morajo spremeniti glede na uporabnika, ki so ga prej ustvarili. Če na primer ustvarijo drug VHost z drugim uporabnikom (forum na primer) potem namesto bloga preprosto vstavite forum v vsako vrstico, ali je to razumljivo?

4. Ko bo konfiguracija novega bazena (datoteko blog.conf, ki smo jo pravkar ustvarili in uredili), na vrsti je, da Nginxu VHost naročite, naj za to spletno mesto uporabi drugo nogavico za ta VHost. Uporabljena nogavica bo tista, ki smo jo predhodno prijavili (/var/run/php5-fpm-blog.sock). Uredimo Nginx VHost in v delu za obdelavo PHP označimo uporabo nogavic. Na primer:

lokacija ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.nogavica;
vključi fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Kot vidite, navedem, da je PHP obdelava tega VHost (te vrstice so na primer znotraj / etc / nginx / sites-enabled / vhost-blog) naredite to z nogavicami, ki jih najdete v /var/run/php5-fpm-blog.sock ..., ki smo jo ustvarili prej pri urejanju /etc/php5/fpm/pool.d/blog.conf ... je ni razumel?

5. Ko je to končano, znova zaženemo obe storitvi (php5-fpm in nginx) in voila, videli bomo, da obdelave te strani (vhost) NE izvaja www-data ali root ali kdo podoben, ampak uporabnik, ki ga predhodno opredeljena.

Tukaj vam pokažem rezultate a ps pomožni | grep fpm na enem od strežnikov mojega vozlišča:

ps pomožni | grep fpm ebook 586 0.0 0.0 349360 1204? S 30. marec 0:00 php-fpm: e-knjiga bazena 589 0.0 0.0 349360 1204? S 30. marec 0:00 php-fpm: e-knjiga o bazenu www 608 0.0 0.2 350084 5008? S 30. mar. 0:00 php-fpm: bazen www www 609 0.0 0.2 350600 5048 30? S 0. marec 00:3 php-fpm: bazen www tv611 0.0 0.0 349360 1204 30? S 0. marec 00:3 php-fpm: bazen tv3 tv615 0.0 0.0 349360 1204 30? S mar0 00:3 php-fpm: pool tv1818 magazine 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: revija za revijo bazen 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: učenec revije za bazen 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: revija učencev bazena 1.8 1.7 437764 36152 10? S 22:0 18:2754 php-fpm: revija pool gutl 3.5 1.3 356724 27164 10? S 38:0 00:5624 php-fpm: gutl bazena cgr 0.0 1.0 365168 22696 28? S apr. 0 16:7900 php-fpm: bazen cgr učenec 0.3 2.5 457052 52444 25? S 20. april 23:11021 php-fpm: učenec bazena učenec 0.4 2.5 458316 52864 28? S 5. april 57:11254 php-fpm: učenec bazena cgr 0.0 1.0 363152 21708 28? S apr. 0 12:13184 php-fpm: bazen cgr cgr 0.0 1.0 362872 21360 28? S 0. april 08:XNUMX php-fpm: bazen cgr

Kot lahko vidite ... ločevanje obdelave PHP s strani uporabnikov, ki uporabljajo Nginx + PHP-FPM, je zelo enostavno, saj vidite, da obstaja več bazenov, saj obstaja več uporabnikov.

Sklepi

Kar zadeva strežnike, nikoli niste dovolj paranoični ... z varnostjo se ne gre igrati, bolj ko se vedno trudimo izboljšati varnost naših strežnikov in njihovih storitev, manj verjetno nas bo (uspešen) poskus vdora ali kaj podobnega 😉


Pustite svoj komentar

Vaš e-naslov ne bo objavljen. Obvezna polja so označena z *

*

*

  1. Za podatke odgovoren: Miguel Ángel Gatón
  2. Namen podatkov: Nadzor neželene pošte, upravljanje komentarjev.
  3. Legitimacija: Vaše soglasje
  4. Sporočanje podatkov: Podatki se ne bodo posredovali tretjim osebam, razen po zakonski obveznosti.
  5. Shranjevanje podatkov: Zbirka podatkov, ki jo gosti Occentus Networks (EU)
  6. Pravice: Kadar koli lahko omejite, obnovite in izbrišete svoje podatke.

  1.   dhunter je dejal

    Gaara, v sedanjih časih bi bilo treba te stvari čim bolj avtomatizirati, priporočam, da preizkusiš Ansible. Brez posrednika potrebujete samo python na oddaljenem gostitelju, zelo enostaven za konfiguriranje, datoteke yaml in predloge Jinja.

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

    1.    KZKG ^ Gaara je dejal

      Poglejmo, to ni vedno samo za spletna mesta WordPress in ... haha, mogoče Ansible klikne volao, ampak raje vem natančno, kako vse deluje na strežniku, tudi če moram minuto porabiti za ustvarjanje novih nogavic in nov VHost 😀

      1.    dhunter je dejal

        Z Ansible avtomatizirate vse, počnete skoraj vse, kar želite, prednost te metode je, da vajo zapirate in nato izvajate po želji, predstavljajte si, da imate močno naloženo spletno mesto in želite izravnati obremenitev med strežniki aplikacij, ti Če je treba konfigurirati popolnoma enako, ne morete preskočiti koraka ali narediti česar koli drugega v enem od njih, si lahko predstavljate, da postopek opravite korak za korakom 4-krat? Z Ansible je tako preprosto kot dodajanje imena gostitelja v datoteko inventarja in Voilá !!

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

      2.    dhunter je dejal

        Žal mi je za kult Ansible, toda to je ena od teh tehnologij, ki jo odkrijete in želite, da jo vsi zdaj uporabljajo, saj je tako kul in praktična, kot če odkrijete NGINX in želite, da vsi vaši prijatelji takoj zapustijo Apache.

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

  2.   mstaaravin je dejal
  3.   Gnilobe87 je dejal

    Sem (ali še študiram) razvijalec in z NGIX sem imel veliko težav pri konfiguriranju nginx + php-fpm. Vem, da distr Archlinux ni najboljši za strežnike, toda vsakič, ko sem posodobil različico ngix ali php, se je vse vedno sesulo, zato sem opustil poskus lol ... Danes ostajam pri klasičnem Apache + PHP, vendar bom videl, ali bom spet obiskal NGIX ... mogoče v navideznem računalniku

    1.    dhunter je dejal

      Miselnost se nekoliko spremeni, nginx služi statični vsebini in služi kot obratni proxy za php-fpm, ki je tisti, ki zažene pravi PHP, začeti morate po delih in korak za korakom doseči uvajanje, poiskati vodnik za uvajanje okvir, s katerim delate, ima vsak svoje podrobnosti z imeni javnosti, statiko, viri itd.

  4.   anonimni je dejal

    Naj si skupnost nakloni opustitev besede "hostear", ki ne obstaja. Za boga, ali je tako težko reči "gostitelj"?

  5.   Želi je dejal

    Lep pozdrav, po vašem zgledu bi rad vedel, ali bi bilo mogoče narediti združenje samo za wordpress backen, to je za wp-admin, ki je naredil novo vtičnico za dohodne povezave z zaledjem

    lokacija / wp-admin {
    root /var/www/yoursite.com/wp-admin;
    indeks index.php index.html index.htm;
    lokacija ~ ^ / wp-admin /(.+. php) $ {
    try_files $ uri = 404;
    root /var/www/yoursite.com/wp-admin;
    vključi / 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/;
    }
    }