Konfigurere Apache: en trinn-for-trinn guide. Apache konfigurasjonsfiler

16.1. Installere Apache Avhengig av distribusjonen, kan pakken som Apache-webserveren er installert fra, kalles apache eller httpd, og dokumentasjonspakken er henholdsvis apache-docs eller httpd-manual. I det første tilfellet må du installere en annen apache-common-pakke som inneholder

16.2. Konfigurerer Apache. Konfigurasjonsfiler Etter å ha installert Apache, bør du redigere følgende filer:? /etc/httpd/conf/httpd.conf er hovedkonfigurasjonsfilen. For Apache 2.x. denne filen kan også kalles httpd2.conf ;? /etc/logrotate.d/apache eller /etc/logrotate.d/httpd (i versjon 2.0) - rotasjonsfil

16.10. SSL og Apache 16.10.1. SSL-installasjon SSL (Secure Sockets Layer) er en krypteringsmetode utviklet av Netscape for å sikre sikkerheten ved dataoverføring. Denne metoden støtter flere krypteringsmetoder og gir autentisering både hos klienten og

19.2. Konfigurasjonsfiler for oppstartslaster Oppføring 19.1 viser hovedkonfigurasjonsfilen for GRUB2, /boot/grub/grub.cfg. Den kan ikke redigeres manuelt. For å lage den brukes verktøyet / usr / sbm / grub-mkconfig, som genererer denne konfigurasjonsfilen basert på maler,

26.2.3. Serverkonfigurasjonsfiler Serverkonfigurasjonsfiler er plassert i katalogen / etc / apache2. Hovedkonfigurasjonsfilen heter apache2.conf. Som standard vil innstillingene passe de fleste brukere. Hvis du planlegger å bruke webserveren ikke bare lokalt (for

Kildefiler og kjørbare filer Vårt fantastiske program, til tross for dets korthet og enkelhet, er et fullstendig meningsløst sett med symboler for en datamaskin, siden det "ikke forstår" direktiver som #include eller printf. Han forstår bare et spesielt språk,

5.3.1. Konfigurasjonsfiler Alle SSH-konfigurasjonsfiler er plassert i katalogen / etc / ssh. Her kan du se følgende liste: SSH-serverkonfigurasjonsfil - sshd_config ;? SSH-klientkonfigurasjonsfil - ssh_config ;? nøkkelfiler for ulike

Konfigurasjonsalternativer for kjernefeilsøking Det er flere konfigurasjonsalternativer som hjelper til med feilsøking og testing av kjernekode, og er inkludert på kompileringstidspunktet. Disse parameterne er tilgjengelige i menyelementet for kjernehacking i redigeringsprogrammet for kjernekonfigurasjon. Alle disse

Apache er verdens mest populære gratis webserver. Fra og med 2016 brukes den av 33 % av alle nettsteder på Internett, som er omtrent 304 milliarder nettsteder. Denne webserveren ble utviklet tilbake i 1995 som en erstatning for den populære NCSA-serveren og har løst mange av problemene. Ryktene sier at navnet hans kommer fra en lapp, siden han fikset NCSA-feil. Nå er det et tverrplattformprogram som støtter Windows, Linux og MacOS og gir tilstrekkelig fleksibilitet, tilpasning og funksjonalitet. Programmet har en modulær struktur, som lar deg utvide funksjonaliteten nesten på ubestemt tid ved å bruke moduler.

Du kan installere Apache på Linux ved å bruke noen få kommandoer, men programmet gir et veldig stort antall innstillinger som kan endres, samt moduler, etter at det er aktivert, vil det fungere bedre. Denne artikkelen vil dekke installasjon og konfigurering av Apache, vi vil bruke Ubuntu som hovedsystem, men du kan gjenta disse trinnene i enhver annen distribusjon. Vi vil vurdere ikke bare installasjonen av selve programmet, men også hvordan du konfigurerer det, konfigurerer virtuelle apache-verter, så vel som de mest nyttige modulene.

For øyeblikket er den nyeste versjonen av programmet 2.4, derfor vil oppsett av apache 2.4 bli vurdert. Som jeg sa, på Linux, er programmet installert med bare et par kommandoer. For å installere på Ubuntu, oppdater først systemet til den nyeste versjonen:

sudo apt oppdatering
$ sudo apt oppgradering

Deretter installerer du apache2:

sudo apt installer apache2

I andre distribusjoner kalles programpakken enten so eller httpd, og du vil ikke ha noen problemer med å installere den.

Etter at installasjonen er fullført, må du legge til webserveren for oppstart for ikke å starte den manuelt etter at du har slått på datamaskinen:

sudo systemctl aktiver apache2

Apache-konfigurasjon

Tiden har gått da Apache-konfigurasjonen ble lagret i en enkelt fil. Men det er også riktig, når alt er distribuert i sine egne kataloger, er det lettere å navigere i konfigurasjonsfilene.

Alle innstillinger finnes i mappen / etc / apache /:

• Fil /etc/apache2/apache2.conf ansvarlig for grunnleggende innstillinger
• / etc / apache2 / conf-tilgjengelig / *- Ytterligere webserverinnstillinger
• / etc / apache2 / mods-tilgjengelig / *- modulinnstillinger
• / etc / apache2 / nettsteder-tilgjengelige / *- innstillinger for virtuelle verter
• /etc/apache2/ports.conf- portene som apache kjører på
• / etc / apache2 / envvars

Som du kan se er det to mapper for conf, mods og site. Disse er tilgjengelige og aktivert. Når du aktiverer en modul eller vert, opprettes en symbolsk lenke fra den tilgjengelige mappen til aktiveringsmappen. Derfor er det bedre å gjøre innstillinger i de tilgjengelige mappene. Generelt sett kunne man klare seg uten disse mappene, ta alt og dumpe det i én fil på gammeldags måte, og alt ville fungere, men nå er det ingen som gjør det.

Først, la oss ta en titt på hovedkonfigurasjonsfilen:

vi /eta/apache2/apache2.conf

Pause- indikerer hvor lenge serveren vil prøve å fortsette den avbrutte overføringen eller mottaket av data. 160 sekunder burde være nok.

Keepalive på- en veldig nyttig parameter, den lar deg overføre flere filer i en tilkobling, for eksempel ikke bare selve html-siden, men også bilder og css-filer.

MaxKeepAliveRequests 100- Maksimalt antall forespørsler per tilkobling, jo flere jo bedre.

KeepAliveTimeout 5- timeout for tilkobling, vanligvis er 5-10 sekunder nok til å laste siden, så du trenger ikke sette mer, men du trenger heller ikke bryte tilkoblingen før all data er lastet.

Brukergruppe- bruker og gruppe som programmet skal fungere på.

Vertsnavnoppslag- logg domenenavn i stedet for ip-adresser, det er bedre å deaktivere det for å få fart på arbeidet.

Loggnivå- feilloggingsnivå. Standard er advarsel, men for å få loggene til å fylles tregere, aktiver bare feil

Inkludere- alle include-direktiver er ansvarlige for å inkludere konfigurasjonsfilene diskutert ovenfor.

Katalogdirektiver er ansvarlige for å angi tilgangsrettigheter til en bestemt katalog i filsystemet. Syntaksen er slik:

Parameterverdi

Følgende grunnleggende alternativer er tilgjengelige her:

Tillat Override- indikerer om .htaccess-filer skal leses fra denne katalogen, dette er de samme innstillingsfilene og samme syntaks. Alle - tillat alt, ingen - ikke les disse filene.

DocumentRoot- setter fra hvilken mappe du må ta dokumenter for å vise til brukeren

Alternativer- indikerer hvilke funksjoner på webserveren som skal tillates i denne mappen. For eksempel, Alle - tillat alt, FollowSymLinks - følg symbolske lenker, Indekser - viser innholdet i katalogen hvis det ikke er noen indeksfil.

Krev- angir hvilke brukere som har tilgang til denne katalogen. Krev alle nektet - for å forby alle, Krev alle gitt - for å tillate alle. du kan bruke bruker- eller gruppedirektivet i stedet for alle for å spesifisere brukeren eksplisitt.

Rekkefølge- lar deg kontrollere tilgangen til katalogen. Godtar to verdier: Tillat, Avvis - tillat for alle unntatt de spesifiserte eller Avvis, Tillat - avslå for alle, bortsett fra de spesifiserte..ru.

Alle disse direktivene brukes ikke her, siden vi er fornøyd med standardinnstillingene, men i .htaccess-filer kan de være svært nyttige.

Vi sitter igjen med filen /etc/apache2/ports.conf:

Den har bare ett direktiv, Listen, som forteller programmet hvilken port det skal kjøres på.

Den siste filen er / etc / apache2 / envvars, som du sannsynligvis ikke vil bruke, den inneholder variabler som kan brukes i andre konfigurasjonsfiler.

Apache-serveroppsett via htaccess

Htaccess-filer lar deg konfigurere webserveren din på Ubuntu til å oppføre seg i en bestemt katalog. Alle instruksjoner spesifisert i denne filen utføres som om de var pakket inn i en tag hvis de var i hovedfilen.

Det er viktig å merke seg at for at serveren skal kunne lese instruksjoner fra .htaccess, skal ikke innstillingene for denne mappen i hovedfilen eller den virtuelle vertsfilen inneholde Tillat Override Ingen slik at alle innstillinger kan fungere du trenger Tillat Overstyr alle.

Når det gjelder resten, kan enhver konfigurasjon av apache-serveren utføres her, fra aktivering av moduler til ganske enkelt å endre tilgang til en mappe. Siden vi allerede har vurdert alle parameterne, vil vi bare gi et par eksempler:

Bestill avslå, tillat
Nekter fra alle

Nekter alle tilgang til denne mappen, det er viktig å søke om konfigurasjonsmapper. Oftest brukes .htaccess for å jobbe med mod_rewrite-modulen, som lar deg endre forespørsler på farten:

RewriteEngine på
RewriteRule ^ produkt /( [^/\.†+)/?$ produkt.php? Id = $ 1 [L]

Men dette er et veldig bredt emne og ligger utenfor rammen av denne artikkelen.

Konfigurering av Apache-moduler

Som jeg sa før, er Apache et modulært program, funksjonaliteten kan utvides ved hjelp av moduler. Alle tilgjengelige moduler, lastere og modulkonfigurasjonsfiler er plassert i mappen / etc / apache / mods-available. Og de som er aktivert i / etc / apache / mods-enable.

Men du trenger ikke å analysere innholdet i disse mappene. Konfigurering av Apache 2.4 ved å legge til moduler gjøres ved hjelp av spesielle kommandoer. Du kan se alle kjørende moduler med kommandoen:

Du kan aktivere modulen med kommandoen:

sudo a2enmod modulnavn

Og deaktiver:

sudo a2dismod modulnavn

Etter å ha aktivert eller deaktivert moduler, må du starte apache på nytt:

sudo systemctl start apache2 på nytt

Under utførelse av en av disse kommandoene opprettes eller slettes en symbolsk lenke til modulfilen med lastutvidelsen i katalogen som er tilgjengelig for mods. Du kan se innholdet i denne filen, det er bare én linje. For eksempel:

vi /etc/apache2/mods-available/deflate.load

Dette er fordi modulen kan aktiveres ganske enkelt ved å legge til denne linjen i apache2.conf-filen. Men det er vanlig å gjøre dette for å unngå forvirring.

Modulinnstillingene er plassert i samme mappe, bare i filen med filtypen .conf i stedet for load. La oss for eksempel se innstillingene til den samme modulen for deflate-komprimering:

vi /etc/apache2/mods-available/deflate.conf

Filene i conf-available-mappen, disse er de samme modulene, bare de er installert separat fra apache, disse kan være konfigurasjonsfiler for å aktivere php-modulen eller et hvilket som helst annet programmeringsspråk. Alt fungerer akkurat likt her, bare kommandoene for å aktivere og deaktivere disse modulene er litt forskjellige:

a2enconf modulnavn

a2disconf-modulnavn

Som du har sett, er det veldig enkelt å aktivere moduler. La oss aktivere noen moduler som er nødvendige, men som ikke er inkludert som standard:

sudo a2enmod utløper
$ sudo a2enmod-overskrifter
$ sudo a2enmod omskriving
$ sudo a2enmod ssl

Expires og header-modulene reduserer belastningen på serveren. De returnerer en Ikke endret overskrift hvis dokumentet ikke har endret seg siden forrige forespørsel. Utløpsmodulen lar deg stille inn hvor lenge nettleseren skal bufre det mottatte dokumentet. Rewrite lar deg endre de forespurte adressene i farten, veldig nyttig når du oppretter NC-lenker osv. Og den siste for å aktivere støtte for SSL-kryptering. Ikke glem å starte apache2 på nytt etter at du har fullført innstillingene.

Konfigurering av Apache Virtual Hosts

Det ville være upraktisk hvis bare ett nettsted kunne være vert på én fysisk maskin. Apache kan støtte hundrevis av nettsteder på en enkelt maskin og levere riktig innhold for hver enkelt. Til dette brukes virtuelle verter. Serveren bestemmer hvilket domene forespørselen kommer til og gir ønsket innhold fra mappen til dette domenet.

Apache vertsinnstillinger er plassert i mappen / etc / apache2 / hosts-available /. For å opprette en ny vert trenger du bare å lage en fil med et hvilket som helst navn (det er bedre å ende opp med vertsnavnet) og fylle den med de nødvendige dataene. Du må pakke alle disse parameterne inn i et direktiv VirtualHost. I tillegg til de vurderte parametrene, vil følgende bli brukt her:

• Server navn- hoveddomenenavn
• Serveralias- tilleggsnavn som siden vil være tilgjengelig under
• ServerAdmin- administrator e-post
• DocumentRoot- mappe med dokumenter for dette domenet

For eksempel:

vi /etc/apache2/sites-available/test.site.conf

Konfigurerer Apache

Det er to måter å konfigurere en webserver på: endre variablene som er ansvarlige for driften av hovedserveren, eller opprette en virtuell server. I vårt tilfelle er den andre metoden å foretrekke. Men mer om det senere, men la oss nå finne ut de grunnleggende direktivene som kontrollerer serverens oppførsel. Hovedkonfigurasjonen for Apache finnes i httpd.conf-filen som ligger i katalogen:

C: \ usr \ local \ apache \ conf \

Dette er en vanlig tekstfil, og et hvilket som helst tekstredigeringsprogram er egnet for å redigere den - for eksempel den samme "Notepad". Jeg vil ikke gå i detalj om hver linje i denne filen, men bare om de mest nødvendige og nødvendige direktivene for oss. Merk at '#'-tegnet er en kommentar, og hvis du kan lese engelsk godt, kan du enkelt skimte dem, noe som imidlertid ikke hjelper mye hvis du ikke har i det minste en generell forståelse av prinsippene for drift av Webservere og om Internett generelt. Så la meg tilby deg min hjelp med å konfigurere Apache. Sammen vil vi lykkes raskere og, viktigst av alt, riktig.

Apache-konfigurasjonsfilen består av tre store deler:

• Globalt miljø - direktiver som kontrollerer Apache-innstillinger generelt;
• Hovedserverkonfigurasjon - direktiver som kontrollerer innstillingene til hovedserveren;
• Virtuelle verter - direktiver som kontrollerer virtuelle servere.

Vi er ikke interessert i den generelle innstillingsdelen, siden det er usannsynlig at du noen gang trenger å endre verdiene som er angitt der, men vi vil analysere de to andre delene mer detaljert. Mer presist, en av dem - jeg vil snakke om nyttige direktiver som brukes når du konfigurerer parametrene til hovedserveren, siden de samme kommandoene brukes når du konfigurerer virtuelle verter. Den eneste forskjellen er at udefinerte parametere arves fra innstillingene til hovedserveren. Så la oss begynne...

ServerName er navnet på webserveren som kjører. Den returneres til klienten i en HTTP-header og identifiserer webserveren som sendte forespørselen. Ved reell drift av serveren på Internett må navnet allerede eksistere og være registrert i DNS. Når du installerer en webserver lokalt for feilsøking og testing av nettsteder, er dette ikke viktig - navnet kan være hva som helst. Dette er forresten navnet installatøren ba om før installasjonen, så hvis du vil, kan du redigere det nå. Parameterverdien må være definert i det minste for hovedserveren. Ellers vil ikke Apache starte.

ServerAdmin [e-postbeskyttet]- administratorens e-postadresse, brukt i noen av de automatisk genererte webserverfeilmeldingene, for eksempel en manglende side. Parameteren må være definert i det minste for hovedserveren, ellers vil Apache også nekte å starte.

ServerRoot "c: / usr / local / apache" er katalogen der Apache ble plassert under installasjonen. Hvis du vil flytte den til et annet sted, må denne linjen justeres, som faktisk alle de andre linjene i filen som peker til denne katalogen. Hvis du installerte Apache som jeg beskrev ovenfor, vil denne linjen allerede være riktig konfigurert og vil peke til c: / usr / local / apache.

Port 80 er porten der Apache vil lytte etter HTTP-forespørsler. Den er standard for webservere og trenger neppe endres.

DocumentRoot "c: / usr / local / apache / htdocs" er adressen til katalogen som brukes til å lagre HTML-sider. Som standard peker denne parameteren til Apache-dokumentasjonen som følger med distribusjonen og ligger i katalogen ovenfor.

UserDir “c: / usr / local / apache / users /” - katalog som brukes til å lagre brukersider, som vil være tilgjengelig på:

Http://www.domain.com/~user/

Siden vi installerer en webserver for lokal feilsøking av nettsteder, og ikke for ekte arbeid på Internett, trenger du ikke å endre denne linjen.

DirectoryIndex index.html index.htm er en parameter som spesifiserer navnet på filen som Apache vil se etter hvis en ufullstendig URL er spesifisert. Det vil si en som slutter med navnet på katalogen, og ikke adressen til en bestemt side. Dette gjelder også for filen som åpnes som standard når du skriver inn hoved-URLen. Hvis du for eksempel skrev inn i adressefeltet:

Http://www.domain.com/links/,

så vil faktisk Apache åpne en side:

Http://www.domain.com/links/index.htm

Den komplette listen over filer som kan finnes i katalogen er nøyaktig definert av denne parameteren. Filnavnene er atskilt fra hverandre med et mellomrom. Rekkefølgen de alternative navnene er oppført i er viktig: hvis katalogen inneholder filer som heter både index.htm og index.html, vil Apache åpne nøyaktig den andre siden, siden index.html er oppført tidligere enn index.htm.

Alias ​​​​/ icons / “c: / usr / local / apache / icons /” - kommandoen for å lage aliaser, det vil si lenker, for alle kataloger. For eksempel gjør kommandoen ovenfor tilgjengelig innholdet i katalogen "c: / usr / local / apache / icons /" på:

Http://www.domain.com/icons/

I dette tilfellet kan selve katalogen ligge hvor som helst i filstrukturen og trenger ikke å være en underkatalog til en tidligere definert katalog for å plassere HTML-dokumenter.

ScriptAlias ​​/ cgi-bin / "c: / usr / local / apache / cgi-bin /" - denne kommandoen ligner den forrige med den eneste forskjellen at den bestemmer den virkelige plasseringen av katalogen med de utførte CGI-skriptene .

AddType text / html .html .htm er en kommando som definerer mime-typen for en fil med en gitt filtype. I dette tilfellet setter vi .html- og .htm-utvidelsene til en normal hyperteksttype, og Apache vil tolke den som html-kode. Mer presist vil nettleseren måtte tolke - webserveren vil bare gi den en indikasjon på at det er hypertekst. Men hvis denne linjen ikke er der, vil Apache gi sider med en slik utvidelse som vanlige tekstfiler.

AddHandler server-parsed .shtml er en kommando som definerer en behandler (automatisk lansert program) for en fil med den angitte filtypen. I dette tilfellet kobler vi .shtml-utvidelsen til den innebygde SSI-direktivbehandleren. Og derfor vil alle filer med denne utvidelsen, før de gis siden til brukeren, gjennomgå forhåndsbehandling. Mer spesifikt vil Apache erstatte alle SSI-innsatser med deres tilsvarende verdier.

ErrorDocument 404 /error404.html - et direktiv som definerer en side som skal sendes til brukeren når en feil oppstår. I dette tilfellet ble siden for den vanligste 404-feilen bestemt. Dette direktivet er valgfritt, og hvis det er fraværende, vil Apache generere en standardside. Men du må være enig i at det er mye mer attraktivt å definere din egen feilside og dessuten lage den i samme stil som nettstedet. Banen til feilsiden kan spesifiseres enten lokalt (da må den nødvendigvis starte fra nettstedets rot), eller med hele URL-en til siden.

ErrorLog logs / error.log - en kommando som definerer navnet på filen der alle feil som oppstår ved lasting av sider eller utføring av CGI-skript vil bli registrert. Når du feilsøker nettsteder lokalt, er dette svært nyttig. Så hvis noe går galt - Apache vil ikke starte, Perl-skript fungerer ikke, grafikk på sidene lastes ikke - denne filen kan hjelpe deg med å finne ut av problemet.

CustomLog logs / access.log common er et direktiv som ligner det forrige, men med den forskjellen at det brukes til å logge alle forespørsler til webserveren. Basert på analysen kan du få en fullstendig rapport om nettstedtrafikk og populariteten til individuelle seksjoner.

La oss nå ta en titt på innstillingene for tilgangsrettigheter til filer og kataloger som er inkludert i strukturen til nettstedet. Av sikkerhetsgrunner må vi angi et visst sett med rettigheter for enhver fil eller katalog som brukes til å lagre sider eller CGI-programmer. Men først, la oss se på hvordan vi kan angi mappen eller filen(e) som vi tildeler rettigheter til. Dette gjøres ved å bruke en av følgende konstruksjoner:

For katalogen:

Alle direktiver som regulerer katalogtilgang og alternativer er oppført her.

For fil(er):

Alle direktiver som regulerer tilgang til filen(e) er oppført her.

De nødvendige verdiene erstattes med katalog og filnavn. Det er mulig å bruke regulære uttrykk, som lar deg angi rettigheter for en hel gruppe filer og/eller kataloger.

Rettighetene som er definert for en katalog gjelder også for alle underkataloger som er inkludert i den, med mindre rettighetene er overstyrt for noen av underkatalogene. Nå vurderer vi en måte å definere rettigheter i hovedkonfigurasjonsfilen på, men for samme formål kan du bruke lokale .htaccess-filer som ligger i mappen du vil begrense tilgangen til. I noen tilfeller er dette mye mer praktisk. Syntaksen for å skrive kommandoer i .htaccess-filen er fullstendig lik syntaksen for kommandoer i httpd.conf-filen.

Det er viktig å merke seg at konfigurering av webserveratferd ved hjelp av .htaccess bare er mulig hvis det er tillatt i den overordnede katalogtillatelsen. Men jeg vil si mer om dette når vi kommer til riktig lag. I mellomtiden, la oss begynne å demontere for alle hoveddirektivene som brukes til å bestemme rettighetene:

• Options option_list er et direktiv som definerer tilleggsalternativer for en spesifikk katalog. Alternativene er atskilt fra hverandre med mellomrom. De viktigste er som følger:
• Ingen - ingen tilleggsalternativer definert for denne katalogen.
• Alle - alle mulige alternativer er definert, bortsett fra MultiViews.
• Indekser – et alternativ som lar deg bruke standardfilene – hvis adressen ikke er fullstendig. Standardlisten over filer er satt av DirectoryIndex-direktivet, som ble beskrevet litt tidligere i denne artikkelen. Hvis det ikke er noen fil i denne katalogen, vil Apache vise innholdet i katalogen til nettleseren som standard.
• Inkluderer er et alternativ knyttet til funksjonen til SSI og tillater bruk av Inkluder-direktivet. For at SSI skal fungere fullt ut, må alternativet være aktivert.
• IncludesNOEXEC - et alternativ som ligner på det forrige, men som forbyr bruk av SSI-kommandoer for å starte et CGI-skript i includeog.
• ExecCGI - et alternativ som tillater lansering av CGI-programmer i denne katalogen.
• FollowSymLinks er et alternativ som lar Apache følge symbolske lenker på UNIX-systemer. Det vil si at siden kan være plassert utenfor hovedtreet som er definert for lagring av html-dokumenter.
• AllowOverride er et direktiv som tillater overstyrende tilgangsparametere for de underliggende katalogene. Det jeg snakket om tidligere. Denne kommandoen må følges av en liste over direktiver som er tillatt å overstyre. For eksempel, AllowOverride All - tillater overstyring av alle rettigheter, AllowOverride Options - tillater overstyring av alternativer for katalogen, AllowOverride None - nekter overstyrende rettigheter.
• Ordre tillate, nekte - rekkefølgen for å gi tilgangsrettigheter til en fil eller katalog fra spesifikke IP-adresser eller domenenavn. En maske kan brukes til å filtrere ut hele nettverkssegmenter. I dette tilfellet bestemmes først nettstedene som tilgang er tillatt, og deretter de som det er forbudt til. Når det gjelder ordrenekt-kommandoen, er tillat det motsatte.
• Tillat fra - en liste over IP-adresser eller domenenavn som tilgang er tillatt fra. En maske kan brukes til å gi en hel gruppe domener tilgang til nettstedet. For eksempel, Tillat fra .com – gir tilgang fra alle domener som slutter på .com. Tillat fra alle – Gir tilgang til nettstedet fra hvor som helst på Internett.
• Nekt fra - en liste over IP-adresser eller domenenavn som tilgang nektes fra. Som i forrige tilfelle kan en gruppe domener eller en maske med IP-adresser spesifiseres.

Dette er kanskje alle hoveddirektivene som brukes når du konfigurerer Apache. Hvis du vil vite hva de andre gjør, så er alt i dine hender - konfigurasjonsfilen er perfekt kommentert og med litt flid kan du finne ut av det.

Nå som Apache er konfigurert og kjører i en grunnleggende konfigurasjon, og vi er bevæpnet med kunnskap om de grunnleggende direktivene, skader det ikke å legge til støtte for andre teknologier – spesielt SSI. Hvis du leser nøye beskrivelsen av kommandoene for å konfigurere Apache, har du sannsynligvis allerede gjettet at denne SSI-teknologien er aktivert ved å spesifisere følgende to direktiver:

AddType text / html .shtml AddHandler server-parset .shtml

Legg til disse to linjene i Dokumenttype-delen av konfigurasjonsfilen (eller bare fjern kommentarer) og juster standardfillisten ved å legge til navnet index.shtml der:

DirectoryIndex index.htm index.html index.shtml

I tillegg må vi definere rettighetene til å bruke SSI-inkluderinger på sidene for katalogen med dokumenter. For å gjøre dette, må du finne og justere delen som definerer rettighetene for dokumentets rotkatalog. Det skal se slik ut:

Alternativindekser inkluderer AllowOverride All

Ingenting annet kreves for å støtte SSI-teknologi, så la oss gå videre til å konfigurere den virtuelle serveren.

Som jeg nevnte tidligere, er virtuelle servere mer praktiske for å lage og feilsøke nettsteder på den lokale webserveren enn å bruke innstillingene til hovedwebserveren til dette formålet. For det første er det veldig enkelt å legge til nye virtuelle servere, for det andre er alle innstillingene knyttet til denne serveren på ett sted, og for det tredje er det veldig enkelt å organisere samtidig støtte for flere prosjekter.

Men før du konfigurerer den virtuelle serveren, la oss lage alle nødvendige kataloger. Jeg anbefaler å bruke katalogstrukturen nedenfor for Internett-prosjekter. Du kan velge hvilken som helst annen stasjon som hovedstasjon, men jeg vil fortsatt bruke stasjon C for forklaringen.

• c: \ web \ - katalog brukt for Internett-prosjekter;
• c: \ web \ project \ - katalog for prosjektet vårt, som vi vil kalle det - prosjekt;
• c: \ web \ prosjekt \ nettsted \ - nettstedsidene vil bli plassert her;
• c: \ web \ project \ cgi-bin \ - CGI-skript i Perl kan plasseres her;
• c: \ web \ project \ logs \ - denne katalogen vil inneholde webserverens loggfiler.

Som nevnt ovenfor, overstyrer direktiver definert i den virtuelle vertsdelen globale verdier. Men først må du finne ut hvordan du definerer selve den virtuelle verten. Dette gjøres ved å bruke VirtualHost-direktivet med samme navn. Nedenfor er et utdrag som beskriver den virtuelle serveren for prosjektet vårt. Legg den til helt på slutten av konfigurasjonsfilen - det er her delen for å definere virtuelle verter ligger. Og så vil jeg gi detaljerte forklaringer på hver linje:

ServerAdmin [e-postbeskyttet] ServerName project DocumentRoot “c: / web / project / website” ScriptAlias​/ cgi-bin / “c: / web / project / cgi-bin /” ErrorLog c: /web/project/logs/error.log CustomLog c: / web /project/logs/access.log felles

Laget? Flott, la oss gå videre til kommentarene! Så i den første linjen definerte jeg IP-adressen som skal brukes for å få tilgang til den virtuelle verten. Siden den lokale webserveren er bundet til IP-adressen 127.0.0.1, er det logisk for virtuelle verter å bruke følgende IP-adresser i rekkefølge: 127.0.0.2, 127.0.0.3, 127.0.0.4 osv.

I andre og tredje linje omdefineres administratorens e-post og servernavn. Disse direktivene er valgfrie, men de lar oss organisere arbeidet med webserveren mer praktisk, spesielt for å gjøre det mulig å få tilgang til serveren ikke via IP-adressen, men med vertsnavnet som er definert i denne delen, men jeg skal fortelle du om det litt senere.

Dette etterfølges av en viktig linje som bestemmer plasseringen av dokumentene for nettstedet vårt. Opptaksformatet er helt likt baseserveren. Aliaser til CGI-skript og stier til loggfiler har blitt redefinert på samme måte. Legg merke til at vi brukte katalogene vi laget noen få avsnitt ovenfor for verdiene.

Etter å ha lagt til den virtuelle verten, må Apache startes på nytt for at endringene skal tre i kraft. Vår virtuelle vert vil nå være tilgjengelig på 127.0.0.2. Hvis noe feiler og serveren nekter å starte, så se på hva som er skrevet i error.log-filen. Mest sannsynlig vil det indikere en feil i syntaksen til konfigurasjonsfilen.

Husker du at jeg lovet å fortelle deg hvordan du lager det slik at du også kan referere til serveren ved navn? Nå er tiden kommet. I konfigurasjonen av webserveren trenger vi ikke lenger å endre noe, men vi må justere den interne Windows-filen som bestemmer samsvaret mellom lokale IP-adresser og domenenavn. Avhengig av hvilket system du jobber med, kan denne filen være plassert på forskjellige steder eller ikke eksistere i det hele tatt (i dette tilfellet må den opprettes manuelt). Filen kalles verter og ligger i katalogen:

C: \ windows \ - for maskiner med Win9x / Me-system

C: \ windows \ system32 \ driver \ etc \ - for maskiner med WinNT / 2000-system

Denne katalogen kan også inneholde hosts.sam-filen (utvidelse fra ordet sample - "eksempel"), som kan omdøpes til verter hvis sistnevnte mangler. Hosts-filen er en ren ASCII-tekstfil og har et veldig enkelt format: hver linje består av en lokal IP-adresse og tilhørende domenenavn. For vårt tilfelle skal denne filen se slik ut:

127.0.0.1 localhost apache 127.0.0.2 prosjekt

Merk at på den første linjen har jeg definert to navn for samme IP-adresse. Et anrop til en slik server er mulig med hvilket som helst av disse navnene. Alternative navn må skilles med mellomrom.

For å teste vår virtuelle server og konfigurerte SSI-teknologi, må vi skrive en testside. For å gjøre dette, lag en fil med følgende innhold i et hvilket som helst tekstredigeringsprogram:

og lagre den som index.shtml. Lag også en test.inc-fil med følgende innhold:

Gratulerer, SSI jobber!

Kopier begge filene til katalogen c: \ web \ project \ website \, som er konfigurert som katalogen for våre prosjektdokumenter, og skriv inn i adressefeltet til nettleseren din:

Http: // prosjekt /

Hvis du ser gratulasjoner i nettleseren, er alt i orden: SSI fungerer, og i tillegg fungerer den nye standardutvidelsen, index.shtml. Hvis noe ikke fungerer som det skal for deg, les de siste avsnittene nøye på nytt og sørg for at du gjorde alt riktig.

Apache er installert og konfigurert - fortsett til å installere og konfigurere PHP.

Installere PHP4 på Windows

Vi vil installere den nyeste PHP-versjonen som er tilgjengelig når dette skrives, nemlig PHP4.0.4pl1. Adressen der du kan laste den ned er angitt på slutten av denne artikkelen. Arkivet med denne PHP-distribusjonen ligger også på CD-en vedlagt bladet.

Distribusjonssettet er et vanlig ZIP-arkiv, og det er nok å pakke det ut i ønsket mappe. Veiledet av de samme hensynene som jeg ga da jeg opprettet katalogen for Apache-installasjonen, pakk ut PHP-distribusjonen i mappen:

C: \ usr \ local \ php4 \

Gå til den spesifiserte katalogen, finn filen php.ini-dist der, og endre navn på den til php.ini, kopier den til Windows rotkatalog (vanligvis c: \ windows). Denne filen inneholder alle innstillingene som kontrollerer PHPs oppførsel og er en ren tekstfil. Siden standardkonfigurasjonen er bra for oss, er det for øyeblikket ikke nødvendig å fikse noe i denne filen.

Nå må du konfigurere Apache og PHP for å fungere sammen. Det er to hovedmåter å installere PHP - som et vanlig CGI-program og som en Apache-modul. Vi skal se på begge og starte med å konfigurere PHP som et vanlig CGI-program.

Installer PHP som et CGI-program

Hovedkonfigurasjonsarbeidet må gjøres på Apache-konfigurasjonsfilen. Hvis du allerede har lukket httpd.conf-filen, åpne den igjen og legg til noen linjer relatert til funksjonen til PHP der. Først må vi definere en ny filtype og tilordne den til utvidelsene som brukes av PHP. For å gjøre dette, legg til følgende linje i "Dokumenttyper"-delen:

Nå må du tilordne en behandler for denne filtypen, så legg til følgende kodebit umiddelbart etter typedefinisjonen:

Alternativer ExecCGI

Til slutt legger vi til index.php-verdien til listen over indeksfiler. For å gjøre dette, finn og korriger følgende linje:

Alle nødvendige PHP-innstillinger er gjort, og du kan teste funksjonaliteten til PHP. For å gjøre dette, lag en testfil med følgende innhold:

og lagre den som test.php i katalogen c: \ web \ project \ website \, som vi tidligere definerte for å lagre prosjektets HTML-filer. Nå, ved å skrive linjen i nettleseren:

Http: //project/test.php

Http://127.0.0.2/test.php,

vi bør se hilsenteksten. Hvis alt er i orden, kan du fullføre konfigureringen av PHP. Ellers, sjekk nøye instruksjonene beskrevet ovenfor i httpd.conf-filen. Ikke glem å starte Apache på nytt før du sjekker.

Å installere PHP som et vanlig CGI-program er ganske enkelt, men det tillater oss ikke å bruke noen av funksjonene knyttet til brukerautorisasjon, permanent tilkobling til databaser og en rekke andre funksjoner. Derfor vil vi nå analysere den foretrukne installasjonsmetoden - som en Apache-modul. Denne metoden gir merkbart raskere ytelse på grunn av fraværet av overhead ved å kjøre et eksternt CGI-program. Men for vårt tilfelle - ved å bruke en lokal webserver for å teste nettsteder - er utførelseshastigheten ikke kritisk.

Installer PHP som en Apache-modul

Det første vi må gjøre er å finne en kompilert PHP-modul for å koble den til Apache. Hvis du installerte PHP som jeg beskrev tidligere, er filen vi trenger på:

C: \ usr \ local \ php4 \ sapi \ php4apache.dll

Kopier denne filen opp ett nivå til PHP-hovedkatalogen:

C: \ usr \ local \ php4 \

Nå må vi sette opp noen variabler i Apache-konfigurasjonsfilen. Som med å installere PHP som et CGI-program, må du legge til en ny dokumenttypedefinisjon i delen Dokumenttyper:

AddType-applikasjon / x-httpd-php .phtml .php

Og korriger også linjen som inneholder listen over indeksfiler:

DirectoryIndex index.html index.htm index.shtml index.php

Nå er det viktigste å konfigurere lasting av modulen. Finn delen "Dynamic Shared Object (DSO) Support" i konfigurasjonsfilen og legg til følgende linje:

LoadModule php4_module "fra: /usr/local/php4/php4apache.dll"

Konfigurasjonen kan anses som komplett. Det gjenstår bare å teste PHP-funksjonaliteten. Bare husk å lagre filen først og start Apache på nytt. For testing kan du bruke det tidligere skrevne test.php-skriptet. Skriv inn linjen i nettleseren:

Http: //project/test.php

og sørg for at PHP kjører. Hvis noe er galt, kontroller nøye nøyaktigheten til banene til modulen du spesifiserte og dens faktiske plassering i den angitte katalogen.

Og en liten merknad for de som allerede har konfigurert PHP som et CGI-program, og nå prøver å installere det som en modul, ikke glem å fjerne delen som kobler filtypebehandleren med CGI-programmet fra Apache-konfigurasjonsfilen. Faktisk, i dette tilfellet er den eksterne modulen allerede engasjert i all behandling av php-filer. Jeg mener dette utdraget:

ScriptAlias ​​"/ __ php_dir __ /" "c: / usr / local / php4 /" Handlingsapplikasjon / x-httpd-php "/__php_dir__/php.exe" Alternativer ExecCGI

Det er her vi avslutter artikkelen vår, og lar beskrivelsen av de viktigste PHP-konstruksjonene ligge til neste gang. Jeg er av den oppfatning at det er lettere å lære av virkelige eksempler, og ikke fra abstrakte konstruksjoner, så neste gang vil vi kombinere forretning med fornøyelse, og studere PHP-konstruksjoner, vil vi skrive et fullt funksjonelt manus - en gjestebok.

ComputerPress 7 "2001

Profesjonell utvikling fokuserer alltid på sine egne verktøy - dette er en garanti for pålitelig og effektiv oppfyllelse av forpliktelser. Egen hosting og servere for ulike formål i spekteret av etterspurte konfigurasjoner utvider omfanget av oppgaver som skal løses, øker sikkerheten og konfidensialiteten til utviklingen.

Innebygd HTTP: Apache, PHP, MySQL

Apache-nettserveren har vært en sterk leder siden forrige århundre fordi den gir rask, pålitelig og sikker drift. En fysisk maskin og server som kjører Linux eller Windows er grunnlaget, HTTP er et tillegg, selv om det i hovedsak er en dataoverføringsprotokoll. En Windows-maskin kan brukes som server, men Linux-familien foretrekkes.

Apache på Windows er en lokal versjon som brukes på en enkelt maskin for å duplisere utviklingsressurser på eksterne servere. Innstilling på er akseptabelt, men ikke veldig populært. Konfigurering av Apache på CentOs gir flere alternativer og brukes til å organisere servere i lokale og globale nettverk.

Det antas at Apache-servere betjener mer enn 50 % av alle aktive nettressurser, resten står for lignende produkter fra Microsoft, Sun osv. Faktisk kan en fysisk server og dens operativsystem være hva som helst. HTTP-serveren er installert på en ferdig plattform og fungerer parallelt med andre applikasjoner på den. Apache regnes som innfødt til hele Linux-familien, men i hvert tilfelle har den sine egne særegenheter.

Frihet, enkelhet, pålitelighet skiller Linux-systemer og deres applikasjoner. Det spiller ingen rolle hvilken du bruker: å installere og konfigurere Apache på Ubuntu er ikke mye forskjellig fra CentOs, Debian eller FreeBSD. Metningen av et bestemt operativsystem med tilleggsprogramvare spiller ofte en rolle.

Linux-familien er liten når det gjelder antall "slektninger" på linjen til en eller annen kjerne i systemet. Forskjellene er mer sosiale av natur - i betydningen av utviklernes vedlegg til formuleringen og implementeringen av funksjonene til operativsystemet.

I virkeligheten, for å løse en spesifikk oppgave for å heve hosting, er det nødvendig å bestemme seg for nødvendig funksjonalitet, nødvendig ytelse, konseptuelle prioriteringer og et spesifikt valg av en Linux-representant, eller velge Windows Server.

Forskyvning av prioriteringer for lokal utvikling

Det er vanskelig å vurdere rollen til det globale nettverket i utviklingen av programmering, men det er lett å legge merke til det virkelige skiftet i tyngdepunktet: lokale applikasjoner begynte å bli utført som en nettressurs. Bare skriv et program for en lokal datamaskin - dette er drivere, antivirus, små prosjekter med enkel funksjonalitet. Programmeringsspråket ... VBA, selv om du kan bruke C / C ++ eller C #.

Ethvert informasjonsprosjekt er en nettressurs i selskapets lokale nettverk, som kan være delvis tilgjengelig fra det globale nettverket, for eksempel for å koordinere handlingene til ansatte utenfor kontoret som er på veien eller på forretningsreise.

MySQL, PHP, Apache: å sette opp for et lokalt brukstilfelle er en helt annen dynamikk i applikasjonen, den nødvendige funksjonaliteten. Moderne selskaper, uavhengig av størrelse, antall ansatte og aktivitetsfelt, vurderer seriøst internettprogrammering, både lokalt og globalt.

I dette tilfellet kan det lokale distribueres: selskapets kontorer kan være lokalisert hvor som helst, men dette er ikke Internett, men et distribuert lokalt nettverk av selskapet.

MySQL, PHP, Apache-innstilling i lokal form:

• enkelt duplisert på tvers av nettverksdatamaskiner;
• gir muligheten til å dynamisk endre den aktive komponenten eller sammenligne den med en prøve for å evaluere hackingforsøk;
• gir en grunn til å utvikle et sikkerhetssystem som er fritt for risikoen for å bli angrepet av klassiske nettverksmetoder.

Tatt i betraktning at MySQL og Apache er tjenester på Windows, og PHP-kode er ren tekst behandlet av et verktøy (PHP-tolk) kalt til rett tid av en HTTP-server, så vil nivået av mutabilitet, portabilitet og portabilitet til koden være mye høyere enn lokale utviklingsverktøy.

Forbereder installasjon av Apache

Tilbake i de første dagene definerte Unix-operativsystemet de uuttalte prinsippene for lojalitet. Siden den gang ble alt som ble gjort for Unix-lignende systemer automatisk oversatt til andre plattformer. Å konfigurere Apache på Windows er enkelt, men seriøse oppgaver krever en god del ferdigheter og detaljert forståelse av HTTP-serverkonfigurasjonen.

Først av alt må du laste ned den nyeste versjonen av serveren (i dag er den versjon 2.4.33 datert 03/17/2018) fra den offisielle nettsiden i zip-arkivformat. Det bør i utgangspunktet tas i betraktning at serverversjonene er mange og tilbys på mange tredjepartsressurser, så det er viktig å velge en offisiell implementering som er vert på en pålitelig nettressurs.

Tidligere var det populært å installere en server ved hjelp av et spesielt installasjonsprogram. Det er nå vanlig praksis å bare distribuere et zip-arkiv. Det er enklere og gjør det mulig å forstå essensen av konfigurasjonsprosessen, som er veldig viktig og deretter lar deg optimalisere serveren for den nødvendige belastningen og funksjonaliteten.

Redigering av konfigurasjonsfilen

Serverkonfigurasjon bestemmes av et sett med konfigurasjonsfiler som ligger i conf-mappen. Hovedkonfigurasjonsfilen for Apache er httpd.conf.

I det overveldende flertallet av tilfeller er det nødvendig å gjøre endringer i hovedfilen, for å klargjøre innholdet i filene som er ansvarlige for ssl og virtuelle verter. Resten av innstillingene gjøres vanligvis i prosessen etter hvert som problemer oppstår eller oppgaver løses. I utgangspunktet er ytterligere innstillinger knyttet til å optimalisere driften av Apache eller utvide funksjonene.

For å lykkes med å starte serveren, er det nok å redigere bare én linje (i rekkefølge - 38.) - og Apache-konfigurasjonen er fullført.

I de tidligere versjonene av serverkonfigurasjonen var det nødvendig å gjøre en rekke endringer for den virkelige situasjonen, men nå er det en "universell" variabel SRVROOT. Det er verdt å spesifisere riktig verdi (banen til serverplasseringen), og alt vil fungere umiddelbart.

Prosedyre for serverplassering

Plasseringen av serveren må vurderes nøye. Apache i seg selv er interessant, men når den er utstyrt med PHP og MySQL, er den dobbelt interessant. Det er bedre når alt relatert til webutvikling er på ett sted. Du kan godta standardbanene, men moderne programmering er ikke så ideell i implementeringen, så du må holde fingeren på pulsen entydig og ofte. I tillegg, når du velger en praktisk plassering, vil alle initialiserings- og konfigurasjonsfiler, samt logger på driften av installerte produkter, være tilgjengelige.

Den nedlastede Apache offisielle zip-filen bør distribueres til stedet du ønsker, og skille verktøyet og arbeidet. I dette eksemplet er C: \ SCiA-mappen et verktøy (Apache24, PHP, MySQL, ...), og SCiB-mappen er faktisk arbeidet til nettsteder som er opprettet, vedlikeholdt eller oppgradert.

Som et resultat av den første fasen av arbeidet er det bare undermappene bin, cgi-bin, conf, error, ... med alt innholdet som kommer inn i mappen C: \ SCiA \ Apache24.

Redigering av vertsfilen

Det andre trinnet er å konfigurere vertsfilen riktig – en indikasjon på hvilke IP-adresser på en gitt datamaskin som er tilordnet hvilke navn. Hvis bare ett nettsted vil bli utviklet eller vedlikeholdt på en datamaskin, kan ingenting endres.

Base IP - 127.0.0.1 peker vanligvis alltid til localhost. Vertens arbeidsfil ligger på c: \ Windows \ System32 \ drivere \ etc og ser ut som nedenfor.

For å plassere vertsfilen på riktig sted, må du bruke kommandolinjen i administratormodus. Du kan forberede det riktige innholdet i filen hvor som helst i filsystemet på datamaskinen din, men du kan skrive den til adressen c: \ Windows \ System32 \ drivere \ etc bare med et verktøy som har administratorrettigheter. Den enkleste måten å gjøre dette på er gjennom kommandolinjen.

Installere Apache Server

Det kunne ikke vært enklere. Det er nok å kjøre kommandolinjen som administrator og gå til mappen C: \ SCiA \ Apache24. Siden dette er en Windows-bane, brukes skråstreker fremover. I et spesifikt tilfelle kan banen være annerledes. Men hvis du på en eller annen måte kan eksperimentere med navnet på mappen for å plassere den hellige treenigheten - Apache, PHP og MySQL, så er det upraktisk å endre mappenavnene for hver av dem.

I dette tilfellet er serverarkivet distribuert i mappen C: / SCiA / Apache24, derfor må du skrive kommandoen i bin-mappen:

• httpd.exe -k installasjon

Serveren vil teste konfigurasjonsfilen og installere seg selv. Mest sannsynlig vil det være mindre feil, men hvis du redigerer konfigurasjonsfilen riktig, vil alle feil være ubetydelige, og de kan raskt fikses.

Vindu (1) kommandolinje - tjenesteinstallasjon, vindu (2) - liste over tjenester der serveren dukket opp, vindu (3) - kildefil index.html, som ligger på C: / SCiB / localhost / www, vindu (4) - resultatet av serveren.

I dette eksemplet ble det med vilje gjort en feil: i stedet for å angi verdien til SRVROOT-variabelen, ble det gjort mange endringer "på gammeldags måte": alt ble endret manuelt. Dette er ikke den beste løsningen. Før du bruker kunnskap, bør du gjøre deg kjent med den gjeldende versjonen av produktet. Som regel endrer ting seg raskt, og kunnskap bør brukes «med kunnskap og forståelse for dagens situasjon».

Praksis for distribusjon av zip-filer

Moderne nettsteder er ikke alltid skrevet på. Det er mye manuelt arbeid. Problemet med å overføre nettstedet til en annen hosting førte til en god løsning - et zip-arkiv. Skjult innhold på ett sted, distribuert - på et annet.

Å ha en installatør er en god praksis, men dynamikken i moderne informasjonsteknologi gir ikke tid til å skrive vakre installasjoner. Installering via zip-distribusjon er moderne, praktisk og praktisk. I dette tilfellet er Apache-konfigurasjonen begrenset til å endre konfigurasjonsfilene.

Når du installerer serveren, er det viktig å spesifisere:

• Hvor befinner han seg;
• hvor er nettressursen (localhost);
• bruker ssl;
• virtuelle verter.

Den siste posisjonen er relevant når den skal utvikle eller vedlikeholde flere ressurser på serveren samtidig. For en ekte utvikler er dette et must: selv om han sørger for driften av ett nettsted, vil det ikke være overflødig å ha en reserve.

Herresett

Det enkle å distribuere zip-arkivet er åpenbart, Apache (installasjon og konfigurasjon) er bare to til tre klikk. Resultatet, da installatører var populære, var imidlertid tilsvarende. Utvikleren brukte ganske enkelt mer tid på å utvikle neste versjon av produktet sitt. Å installere en server, serverspråk og database er i hovedsak bare en haug med filer, starttjenester, en vertsfil og standardstier i operativsystemets variabelbane.

Utseendet til "Denver" og lignende herresett til utvikleren var et revolusjonerende skritt i retning av enkelhet og bekvemmelighet, men gjør ingen feil. Revolusjon og programmering er absolutt uforenlige ting. Den første er et barn av konflikten og dens stormfulle løsning, den andre er en alvorlig sak som krever absolutt ro, punktlighet, nøyaktighet, konsistens, oppmerksomhet, sikkerhet, pålitelighet.

Konfigurering av Apache-serveren er en seriøs prosedyre som må tas veldig nøye og alt bør gjøres slik at du i morgen kan endre og avklare noe.

I de fleste tilfeller er utviklingen av nettressurser en ganske langvarig prosess der kravene til tjenester (Apache, PHP, MySQL, ...) endres raskt, men det er alltid tid til å forstå neste oppgave og dens optimale løsning. Men dette er ikke en grunn til å gå om herrenes sett. Tiden går, men gentlemannen endrer seg ikke, dette er et mye mer tungtveiende argument enn Denver-erklæringen – det er enkelt, raskt og rimelig.

Flere nettsteder - én server

Å konfigurere Apache 2.4 for en enkelt vert er en unødvendig luksus. Til tross for sin kompakte design, bærer denne serveren et enormt ansvar for mer enn halvparten av de aktive nettressursene på Internett. I tillegg har ikke alle ressurser en representativ del og er synlige på nettverket.

Serveren kan brukes som en database, som et informasjonsoverføringspunkt, som et filter, som en parser, som en arbeidsmekanisme i en mer global informasjonsprosess. Som et resultat er konfigurering av virtuelle Apache-verter nesten alltid en obligatorisk prosedyre.

Én server kan støtte så mange nettressurser du vil, for dette må du fjerne kommentaren fra linje 501 i httpd.conf-filen:

• # Inkluder conf / extra / httpd-vhosts.conf

og beskriv alle nødvendige verter i en fil

• ekstra \ httpd-vhosts.conf.

Det kan være nødvendig å avklare hvilke porter og IP serveren lytter til, men dette er et eget tema, for første gang kan du begrense deg til det som er.

Det skal bemerkes at i eksemplet, for enkelhets skyld å beskrive ekte virtuelle nettressurser (og det er mange av dem), introduseres (DOCROOT) variabelen med banen til den delte mappen for alle nettressursene tilgjengelig gjennom den installerte serveren .

Apache SSL-konfigurasjon er tilgjengelig på lignende måte. I httpd.conf-filen trenger du bare å forlate "som den er" linjene 524 til 531, som er ansvarlige for driften av SSL.

Enkelheten og kompleksiteten til Apache

Dagene da det var veldig vanskelig å sette opp en server er for lengst forbi. Å konfigurere Apache i dag er en veldig enkel prosedyre som ikke krever noen spesielle ferdigheter fra utvikleren.

Tre enkle trinn:

• utvide arkivet;
• endre konfigurasjonsfilen;
• installer serveren.

Som et resultat er Apache fullt funksjonell. Hvis du ikke tar hensyn til vanskelighetene ved serveroperasjonen ved maksimal belastning eller utfører lokal utvikling på en Windows-datamaskin, er det ikke nødvendig med ytterligere kunnskap.

Det kan oppstå vanskeligheter på Linux-systemer. Vesentlig forskjellige ideer om filsystemet, bruker- og grupperettigheter, samt organiseringen av prosessen med interaksjon med andre applikasjoner krever mer kompetanse fra utvikleren og forståelse for hvordan Linux-datamaskiner fungerer.

Konfigurering av Apache på et hvilket som helst Linux-system åpner for mye flere muligheter for utvikleren og gir tilgang til det lokale nettverket og Internett. Tradisjonelt er en Windows-datamaskin en lokal arbeidsstasjon med en intern server. Linux-datamaskin - og en lokal nettverksnode eller et punkt i Internett-området.

Profesjonelt utviklermiljø

Apache er en grunnleggende byggestein i Internett-området som enkelt kan konfigureres, brukes og ryggraden i et selskap.

Denne logikken forutsetter tilstedeværelsen av minst én server på nettverket på CentOS, Ubuntu, FreeBSD, Windows arbeidsstasjoner. Det er optimalt å ha to Linux-servere (primær og sekundær), Apache-konfigurasjon for en lokal datamaskin i Windows-miljø. I tilfelle et virusangrep eller en uforutsett situasjon, vil hjelpeserveren erstatte den viktigste, og den viktigste - for reparasjon og restaurering. Du kan erstatte den lokale Apache-installasjonen på en arbeidsstasjon (under Windows) fra arkivet.

Denne trivielle løsningen kan foredles og suppleres i praksis. Størrelsen på bedriftens informasjonsstrømmer kan bestemme ønsket konfigurasjon og nødvendig antall servere. Egentlig er Apache designet for å fungere under belastning, men ingenting hindrer deg i å fordele ansvaret til én server over flere. En løsning som tar hensyn til spesifikasjonene til et bestemt selskap er alltid mer lovende enn å tilpasse et tredjepartsalternativ.