Apache Web Server Administrasjon og e-handelsveiledning. Apache-serveradministrasjon og e-handelsveiledning

Sammendrag

Denne boken var ment å være en ganske omfattende referanseguide via Apache webserver. Materialet som presenteres i det forutsetter et visst nivå av datakunnskap, men kunnskap om nettverksteknologi er ikke nødvendig. Til tross for at hovedutgaven av boken ligger i området e-handel, dekker applikasjonene et bredt spekter av problemer og informasjon som trengs for å lage og drive en webserver. Dette er problemet med å matche navn og IP-adresser, TCP/IP-protokolldetaljer og syntaks vanlig uttrykk. I tillegg, fra webadministrasjonens perspektiv, berøres temaene for å lage et system elektroniske betalinger og interaksjon med databaser.

Apache

Apache-nettserveren har blitt kalt kronjuvelen til åpen kildekode-programvarebevegelsen. Du kan få det helt gratis. Den har utmerket ytelse og er derfor mer utbredt enn alle andre webservere til sammen. I for tiden 61,5 prosent av alle nettsteder i verden er opprettet ved hjelp av Apache server.

Utbredelsen av "åpen kildekode-systemer" ligner mye på prosessen med naturlig biologisk utvalg - alle Linux-operativsystemer og sendmail-verktøy i verden fyller gradvis forsiden av magasinet Time og blir knust av reklamemaskinen mens legioner av DOS-verktøy sakte men ubønnhørlig nærme deg /dev/-enheten. null-historikk. Apache ville aldri vært så populær hvis det ikke fungerte pålitelig.

Apache-serveren har enda en fordel som ikke er iboende i de andre åpne systemer: Det er så enkelt at enhver tilstrekkelig dyktig bruker kan mestre det i sin helhet. Gud vet, jeg er ingen stor Microsoft-fan, men hvis jeg fikk i oppgave å velge mellom Linux OS og Windows 2000 OS, ville jeg umiddelbart valgt Windows før du kunne blinke med et øye. Og forresten, dette bør ikke betraktes som manglende respekt for Linux: Operativsystemer, spesielt flerbruker, er veldig komplekse. Den eneste måten å gjøre dem tilgjengelige for den gjennomsnittlige brukeren er å forenkle dem.

Heldigvis er ikke settet med oppgaver som kan løses ved hjelp av Apache-serveren så bredt. De av dere som begynner å lære en server med usikkerhet og en følelse av frykt for nye ting, vil bli lettet over å vite at selve serverkonfigurasjonen og vedlikeholdsprosedyrene ikke er veldig vanskelige. Essensen av å mestre en server, avhengig av erfaringsnivået ditt, er å mestre de grunnleggende konseptene til operativsystemet, mestre kommandoene som vil hjelpe å få maskinen til å gjøre det du vil, og mestre språket. Hvis du er ekspert på en av disse problemene, finner du egentlig en hyggelig overraskelse.

Novelle

Apache-serveren kommer fra httpd-serveren opprettet av Rob McCall (Rob McCool) V Nasjonalt senter om bruk av superdatamaskiner (National Center for Supercomputing Applications - NCSA). I 1995 var httpd den mest populære nettserveren som eksisterte, men da i 1994 McCall forlot NCSA, frøs utviklingen av programmet. Derfor, for å støtte og utvikle den, samlet en liten gruppe nettadministratorer seg og dannet kjernen i en organisasjon som nå er kjent som "Apache-gruppen." Dens medlemmer er

Brian Behlendorf (Brian Behlendorf)

Roy T. Fielding(Roy T. Fielding)

Rob Hartill (Rob Hartill)

David Robinson (David Robinson)

Clif Skolnik (Cliff Skolnick)

Randy Terbush (Randy Terbush)

Robert Thau (Robert S. Thau)

Andrew Wilson (Andrew Wilson)

I nært samarbeid med Erik Hagberg (Erik Hagberg), Frank Peters (Frank Peters) Og Nicholas Pioch (Nicholas Pioch), "Apache group incorporated" publiserte feilrettinger for httpd 1.3, la til flere nye funksjoner og ga i april 1995 ut neste versjon av serveren under navnet Apache 0.6.2.

Siden den gang har «Apache-gruppen», som de snart ble kjent, viet seg til å tilpasse og forbedre programvaren. Det finnes nå versjoner for nesten alle større operativsystemer, selv om Unix-plattformen er den ubestridte lederen blant dem.

I kjernen er Apache-nettserveren sluttresultatet av det enorme samarbeidet mellom en gruppe høyt kvalifiserte programmerere. Et naturlig spørsmål dukker opp om hva som fikk dem til å jobbe med Apache i stedet for å utvikle vanlig kommersiell programvare for gode penger. Du kan sitere nettstedet her apache.org:

"Apache-serveren eksisterer for å tilby pålitelige, kommersielle løsninger ved hjelp av HTTP-protokoll. Det gir en plattform der enkeltpersoner og organisasjoner kan bygge pålitelige systemer for både eksperimentelle og virksomhetskritiske applikasjoner. Vi tror at verktøyene som er publisert på Internett, som faller i hendene på noen eller selskaper som er involvert i utviklingen av programvareprodukter, vil være i stand til å tjene penger ved å lage Tilleggstjenesterå lage spesialiserte moduler og tilby tjenester for teknisk støtte. Vi forstår at det å «eie» markedet er en økonomisk fordel, og i programvareindustrien betyr dette at det er nok å kontrollere mottak av betalinger fra brukere av programvareproduktet. Vanligvis kan denne tilstanden oppnås ved å "eie" protokollen som selskaper driver sin virksomhet med. Fordi protokollene som brukes på Internett er «ingenmannsland», er det fortsatt domenet til store og små selskaper. På denne måten ser det ut til å være mulig å forhindre "privat eierskap" av protokollen og sikre eksistensen av et pålitelig programvareprodukt som bruker protokollen, tilgjengelig helt gratis for alle selskaper, og dette kan ikke undervurderes."

Programvare med åpen kildekode

Apache-nettserveren kan enkelt klassifiseres som en av galaksen av såkalte open source-programvareprodukter. Tradisjonelt leverte arkiverte applikasjonsprogrammer inneholder vanligvis bare den kjørbare objektkoden, i stedet for kildekoden som programmet ble kompilert fra. Apache og andre lignende produkter inkluderer i sine distribusjoner ikke bare den kjørbare objektkoden, men også kildekoden som objektkoden ble opprettet fra.

Fra synspunkt slutt bruker det gir mening. For eksempel, mens du jobbet med denne boken, oppsto det mange problemer på kontoret vårt. Stor kommersiell programvare som kjørte på et stort kommersielt operativsystem ble ikke respons. Den sluttet å svare på innspill. Vi prøvde å spore stabelen og noen andre ting, men i mangel av kildekoden klarte vi ikke å ta noen vesentlige skritt. Derfor ble alt fjernet mulig diagnose og ble sammen med programvaren overført til leverandøren for analyse. Helt naturlig ble problemet løst, men det tok to uker.

Derfor er det en svært kompleks prosedyre. Hvis vi jobbet med åpen programvare, så ville en løsning definitivt blitt funnet mye raskere. Og i dette konkret tilfelle Det var ikke klart hva problemet var, og selv om vi visste årsaken, ville vi definitivt ikke kunne fikse det. Vi var fullstendig prisgitt leverandøren vår.

Å jobbe med "åpne systemer" er selvfølgelig noe uvanlig. Når det gjelder arbeid med åpen kildekode, er det faktisk ingen som er direkte ansvarlig for vedlikehold åpen versjon Apache-server, nei gratisnummer, som du kan ringe klokken 02.00 hvis noe skjedde med serveren og du ikke vet hva du skal gjøre. Støtte finnes i form av nyhetsgrupper og nettsider, men det kommer når det passer for den som gir støtten, ikke for den som trenger det.

Apache webserver, som andre programvareprodukter klasse "åpen kildekode-programvare" drar bare nytte av deres konstante tilgjengelighet for programmeringsfellesskapet. Fordi det er mange flere utviklere som jobber med hvert "åpen kildekode"-prosjekt enn selv det rikeste selskapet kunne ansette, oppdages buggy-kode og fikses mye raskere.

La meg foreslå at kvaliteten klartekst vanligvis høyere enn kommersielle produkter. Tross alt er hovedmotivasjonen til utviklere som jobber med "åpne" produkter kjærligheten til programmering som en kreativ prosess. Når du arbeider med "åpne produkter" kan du dermed få mest mulig ut beste prøvene programmer. Dette står i sterk kontrast til et kommersielt produkt hvor mesteparten av arbeidstiden brukes på møter, telefonsamtaler og til slutt beholdning av saldoer.

Strukturen til denne boken

Boken er beregnet på Apache-serveradministratorer med ulike kvalifikasjoner. Det forventes kjennskap til de grunnleggende konseptene som brukes i dataindustrien. Ingen spesiell opplæring er nødvendig for webadministrasjon. For de som er helt nye på Apache-serveren, er det en ganske stor introduksjonsseksjon der du kan finne alt du trenger for å komme i gang så raskt som mulig.

Etter å ha gjort deg kjent med de grunnleggende konseptene, kan du bli fristet til raskt å implementere en serverfunksjon eller to (for eksempel delt hosting). Kapitlene i denne boken er organisert i uavhengige, frittstående essays som dekker en rekke emner. Og du kan lese dem i hvilken som helst rekkefølge.

På grunn av sin åpenhet mot verden, blir Apache-serveren stadig forbedret. Nye funksjoner tilbys og legges til hver dag. Noen ganger er det en forbedring grunnleggende funksjoner servere, men oftest - nye eller forbedrede moduler. Av denne grunn må selv erfarne administratorer utvide sine kompetanseområder fra tid til annen. Jeg håper denne boken har noe av verdi å tilby selv erfarne Apache-administratorer.

Til slutt diskuterer vedleggene en rekke nettverks- og programmeringsemner. Mange av disse er ikke direkte relatert til Apache-serveren, men siden Apache-serveren krever et fungerende nettverk, vil din karriere som webadministrator sannsynligvis kreve litt kunnskap om generell nettverksadministrasjon og programmering. Appene er ikke altomfattende, men de kan være svært nyttige.

Del I, "Grunnleggende"

Del I dekker grunnleggende konsepter og teknikker for å administrere Apache-serveren. Den vil lede deg gjennom prosessen med å skaffe og installere en Apache-server konfigurert for å passe dine behov. Hvis du er ny på Apache-serveren, må du mest sannsynlig lese alle fire kapitlene i rekkefølge, spesielt kapittel 1, "Grunnleggende konsepter." Informasjonen i kapitlene 1 til 4, sammen med vedleggene, er nok til å få enhver nybegynner i gang.

Del II, "Web Server Administration"

Del II beskriver mer komplekse funksjoner Apache server. Og hvis du mestrer de grunnleggende serverkonseptene, kan du hoppe over kapitlene i denne delen. Hvert kapittel ble tenkt som et selvstendig essay om et emne som er tydelig fra selve kapitteltittelen.

Del III, "Elektronisk handel"

Del III diskuterer spørsmål som er direkte relatert til elektronisk handel, interaksjon med databaser og mekanismer for å tjene penger ved å bruke Internett. Det siste kapittelet i denne delen er en casestudie om å lage en kommersiell knutepunktinfrastruktur.

Del IV, "Vedlegg"

Vedleggene inneholder informasjon som er for spesialisert til å inkluderes i resten av boken (som direktivsyntaks) eller som kan beskrives som relatert informasjon (som vedlegg E, "Unix-konsepter"). Noen av dem presenteres i form av korte pedagogiske essays, andre - som enkelt referansemateriale.

Hvordan bruke denne boken

I materialet som presenteres i boken, kan du finne eksempler på kommandoer og konfigurasjonsdirektiver, vanligvis ledsaget av forklaringer og noen ganger utskrifter. Detaljert informasjon om syntaks av direktiver og systemkommandoer ikke i hovedkapitlene. Slik informasjon finnes i vedleggene, spesielt i vedlegg A, "Generelle direktiver", og B, "Andre direktiver". Forhåpentligvis, ved å se på en kommando som er ukjent for deg, kan du bestemme bruken.

Suksessen eller feilen til en gitt Apache-servertransaksjon avhenger av serverens interne konfigurasjon, innholdet som overføres, operativsystemkonfigurasjonen og lunkene til nettverksstøttetjenester. Derfor er det umulig å si med full sikkerhet om eksemplene som presenteres her vil fungere på en bestemt maskin. Forfatteren kan bare sverge med fullt ansvar at de alle jobbet for ham.

I noen tilfeller ble det innledende temaet for et bestemt kapittel etablert i forrige kapittel. For eksempel ble de virtuelle vertene diskutert i kapittel 8, «Sikkerhet», diskutert i kapittel 4, «Start, omstart og stopp». Hvis betydningen av et bestemt konfigurasjonsdirektiv er uklart, kan du bli bedt om å konsultere emneindeks eller les om formålet i tidligere kapitler.

Det bør understrekes at i eksemplene på operativsystemkommandoer er det foretrukket Unix OS-kommandoer generelt og Linux OS-kommandoer spesielt. Det er ingen tilfeldighet i dette, for når denne boken ble skrevet var det en Linux-maskin som ble brukt som testserver, noe av arbeidet ble utført på Windows NT, Windows 95 og Mac OS X.

En av Unix-konvensjonene som jeg er veldig stolt av, men som ikke finnes noe sted i Apache-serverdokumentasjonen, er praksisen med å deklarere en miljøvariabel. Den kan lagre en lang vei til katalogen. I boken kan du se Unix OS-systemvariabelen $APACHE, som lagrer navnet på katalogen der Apache-webserveren er installert. (Denne katalogen blir referert til som ServerRoot i konfigurasjonsfilene.)

Typografiske konvensjoner

Unix bruker en spesiell font for å vise kommandoer, direktiver, navn og meldinger:

Eksempel på et direktiv med parametere

Store eksempler på konfigurasjonsfiler leveres vanligvis separat.

DirektivA

DirektivB

DirektivC

DirektivD

Til slutt har jeg forsøkt å dele opp beskrivelsen av direktivene ved å bruke overskrifter som gir mening. Mens de fleste Apache-serverdirektiver har navn som gir nok erfaren bruker et hint om funksjonene deres (for eksempel AddModule og Port), andre er relatert til funksjoner som er unike for Apache-webserveren og er vanskelige å beskrive med tolv tegn (for eksempel DocumentRoot).

Alle spørsmål, kommentarer, rettelser eller forslag til forbedringer kan sendes til: [e-postbeskyttet] .

Hydra

I stedet for et etterord, vennligst aksepter mine tanker om betydningen av skapningen som er avbildet på forsiden av denne boken. Dette er en hydra, den ble tegnet av en fyr som heter Tom Post (Tom Post). Mytologiske beist har blitt et tradisjonelt tema for omslagsdesign av bøker om åpne systemer utgitt av Prentice Hall. Så Hydra er en ganske passende personifisering av Apache. Tross alt minner mange Apache-forekomster som kjører samtidig på én datamaskin veldig om mange hydra-hoder. Er det ikke riktig? For et så vellykket valg av et mytologisk bilde med skarpe tenner, vil jeg takke redaktøren min Miles Williams (Miles Williams), og også fordi han ikke plaget meg med alle slags enhjørninger, nymfer og andre onde ånder.

HTTPS (HyperText Transfer Protocol Secure) er ikke en uavhengig protokoll, men en utvikling av HTTP (HyperText Transfer Protocol) mot sikkerhet. Det vil si at en mekanisme for kryptering av overførte data ble lagt til vanlig HTTP. Kryptering er implementert ved hjelp av SSL (Secure Sockets Layer). Hvordan fungerer dette i praksis?

Når du kobler til serveren via HTTPS-protokoll(standard TCP-port 443), sier nettleseren og serveren først hei, utveksler støttede krypteringsalgoritmer og blir enige om hvilken algoritme de skal bruke. Serveren gir den til nettleseren offentlig nøkkel(sertifikat) som skal brukes til kryptering. De er kort sagt enige om gjensidig fordelaktig samarbeid. Vanligvis klarer de å komme til enighet og etablere en sikker forbindelse. Alt dette skjer på lag seks av OSI-modellen. Og først etter dette trer HTTP i kraft, som opererer på applikasjonsnivå - det syvende nivået.

For å aktivere HTTPS-støtte for allerede installert Apache påkrevd: , , og (Eller ).

Generering av et selvsignert sertifikat

Vi går til Apache-katalogen der nøklene er lagret.

# cd /etc/apache2/ssl

Opprett et selvsignert sertifikat og en ny servernøkkel uten passord:

# openssl req -new -newkey rsa:1024 -nodes -keyout citename-CA.key -x509 -days 365 \
" \
-out citename-CA.crt

Kommandoargumenter:

Vi setter tilgangsrettigheter til nøklene.

# chmod 600 /etc/apache2/ssl/*.crt

Sette opp en apache-server

Aktiver SSL-støtte i serveralternativlinjen. For å gjøre dette, legg til -D SSL der

Virtuell vertskonfigurasjon

Konfigurer den virtuelle vertsfilen. En standard virtuell vert er også mulig hvis støtten er aktivert i Apache.

Alt som gjenstår er å starte Apache på nytt

# /etc/init.d/apache last inn på nytt

Konfigurere flere virtuelle verter for å fungere med SSL

For eksempel er det tre verter med samme IP-adresse: citename.ru, shop.citename.ru, cite-name.ru. For dem må du opprette tre nettsteder med forskjellig innhold og få tilgang til dem via HTTPS.

Vi lager selvsignerte sertifikater for dem.

# cd /etc/apache2/ssl
# openssl req -new -newkey rsa:1024 -nodes -keyout citename-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=Salg/CN=citename.ru/emailAddress= Denne e-postadressen er beskyttet mot spambotter. Du må ha JavaScript aktivert for å se den. " \
-out citename-CA.crt
# openssl req -new -newkey rsa:1024 -nodes -keyout shop-citename-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=Salg/CN=shop.citename.ru/emailAddress= Denne e-postadressen er beskyttet mot spambotter. Du må ha JavaScript aktivert for å se den. " \
-out shop-sitename-CA.crt
# openssl req -new -newkey rsa:1024 -nodes -keyout cite-name-CA.key -x509 -days 365 \
-subj "/C=RU/ST=Arkh/L=Arkh/O=OAO/OU=IT/CN=siternavn.ru/emailAddress= Denne e-postadressen er beskyttet mot spambotter. Du må ha JavaScript aktivert for å se den. " \
-ut oppgi-navn-CA.crt
# chmod 600 /etc/apache2/ssl/*.crt
# chmod 600 /etc/apache2/ssl/*.key

Og vi konfigurerer virtuelle verter.

Så langt har vår fortelling vært begrenset til de enkleste tilfellene. Dette er når en forekomst av Apache-serveren er installert på én vertsmaskin og den serverer kun én IP-adresse for å behandle brukerforespørsler som kommer til ett nettsted. I praksis er dette alternativet usannsynlig. Mer sannsynlig er det dusinvis om ikke hundrevis av noder, hver med spesifikke ressurs- og konfigurasjonskrav.

Apache-serveren kan konfigureres til å støtte flere IP-adresser (se BindA-adressen og Listen-direktivene). For hver IP-adresse kan den støtte flere porter1. Hver kombinasjon av tilstedeværende IP-adresser og porter har en eller flere noder. Dette kapittelet beskriver tre metoder for å sette opp en Apache-server til å være vert for flere noder:

1. Brukerhjemmesider.

2. Virtuell hosting etter navn.

3. Virtuell hosting etter IP-adresse.

Den første metoden - tilpassede hjemmesider - er den enkleste, men det er usannsynlig å tilfredsstille brukere som ønsker å betale penger for denne tjenesten. Denne metoden oppretter brukerunderkataloger i brukerkatalogen, og Apache omdirigerer alle forespørsler om hjemmesider til brukerkatalogene.

1 Begrepene IP-adresse og port er omtalt i detalj i vedlegg A, Generelle retningslinjer.

Delt hosting er en Apache-serverfunksjon som lar én server håndtere forespørsler til flere ulike web noder Serveren er konfigurert på en slik måte at den skiller forespørsler om virtuelle noder ved navn, IP-adresse eller begge deler. Apache-serveren kan konfigureres slik at forskjellige noder påvirkes av forskjellige direktiver (og derfor oppfører seg forskjellig). For disse formålene brukes virtualHost-direktivet. Som standard arver virtuelle noder egenskapene til hovedserverforekomsten. Imidlertid kan nesten alle grunnleggende serverdirektiver enten ignoreres eller suppleres av virtualHost-direktivet.

Delt hosting er veldig populært av økonomiske årsaker. Titusenvis av noder med lav til moderat trafikk kan støttes med bare én fysisk node. Det anbefales å registrere domenenavn. Det er vanligvis et gebyr for flere navn. Virtuell hosting utføres med navn eller IP-adresse.

Den andre metoden, virtuell hosting etter navn, innebærer å knytte flere servernavn til en enkelt IP-adresse. Ettersom mangelen på IP-adresser øker, øker sannsynligheten for å bruke denne metoden.

Du har sikkert allerede gjettet at den tredje metoden, i delt hosting etter IP-adresse, er at én maskin er vert for mange IP-adresser. Tidligere var dette den eneste metoden for flere hosting og nå er det fortsatt den eneste løsningen for å håndtere trafikk som kommer fra eldre versjoner av nettlesere2. IP-adresser kan assosieres med flere nettverkskort(NIC). På den annen side lar moderne operativsystemer deg støtte flere IP-adresser ved å bruke et enkelt nettverkskort.

For at konfigurasjonsendringer skal tre i kraft, må Apache-serveren startes på nytt som vanlig.

5.2. Brukerhjemmesider

Denne metoden bruker UserDir-direktivet til å plassere URL-en i noen kataloger på systemet, som vist i fig. 5.1.

5.2.1. UserDir some_directory-direktiv

Dette direktivet er ment å indikere at webinnhold vil bli funnet i en spesifikk underkatalog av brukerens rotkatalog. Når dette direktivet kjører, godtar Apache-serveren forespørsler i formen:

http://www.example.com/~brukerguy

og bruker systemressurser for å bestemme brukerguys rotkatalog. La oss si at det er i /home-katalogen, så banen til rotkatalogen userguy vil være /home/userguy. Hvis et direktiv som ligner på

UserDir some_directory,

Apache-serveren vil se etter webinnhold som skal vises i underkatalogen some_directory i /home/userguy 3-katalogen. I henhold til logikken i vårt eksempel vil dette føre til katalogen

/home/userguy/some_directorу

2 Nettlesere som implementerer HTTP-standarder mindre enn 1.1, av grunner som vi vil diskutere senere, kan ikke støtte hosting etter navn.

3 Standardverdi public_html

Ris. 5.1. Brukerhjemmesider

5.2.2. Direktiv UserDir /an/absolute/path

Det er en måte å sette den absolutte banen til en bestemt katalog der nettinnholdet til alle brukere er lagret. Denne metoden forutsetter at hver bruker har sin egen underkatalog i katalogen spesifisert av UserDir-direktivet. For eksempel hvis Apache-serveren mottar en URL

http://www.example.com/~timmy/x fluer.html,

når UserDir /var/user/webspace-direktivet er i kraft,

så returnerer serveren /var/user/webspace/timmy/x files.html

5.2.3. Direktiv UserDir /an/absolute/*/with/wildcard

Av alle tre alternativene for UserDir-direktivet, er dette alternativet den mest sannsynlige kandidaten for bruk. Denne metoden spesifiserer den absolutte banen til katalogen der brukere lagrer webdokumentene sine. Her, i stedet for brukernavnet, vises en stjerne "*". Og når Apache-serveren mottar en forespørsel til en bestemt bruker

http://www.example.com/~susie,

den analyserer brukernavnet (angitt med "~"-tegnet) og erstatter stjernen med brukernavnet. For eksempel, hvis UserDir-direktivet for øyeblikket er i kraft:

UserDir /home/*/public_html,

Apache-serveren vil omdirigere denne URL-en til /home/susie/public_html-katalogen

5.3. IP-adresser og porter

Før du konfigurerer delt hosting, må du konfigurere serveren til å lytte på de riktige portene. Som standard overvåker Apache-serveren IP-en

port 80 for alle IP-adresser som er tilgjengelige på serveren. Avhengig av oppgavene serveren står overfor, kan dette være tilstrekkelig. Direktivene beskrevet i denne delen lar deg konfigurere adressene dine og overvåke porten.

5.3.1. Bestemme IP-adresser:

BindAddress adressedirektiv

BindAddress-direktivet forteller Apache-serveren å overvåke en spesifikk IP-adresse eller en rekke adresser. Følgende direktiv setter Apache-serveren til å lytte til adressen 192.168.1.10:

Bindadresse 192.168.1.10

For å lytte til alle aktive IP-adresser, må du spesifisere kommandoen

5.3.2. Definere én IP$port: Portportnum-direktiv

Som standard lytter Apache-serveren på IP-port 80 til den oppgitte IP-adressen. Dette er riktig fordi port 80 er "standardporten" definert av HTTP-protokollen og vil derfor få tilgang til det største antallet nettlesere.

På den annen side kan det hende du må endre dette standard installasjon og dermed begrense tilgangen til bare de nettleserne som kjenner lytteporten. Et typisk eksempel på slik bruk av Apache-serveren er bruken som proxy-server, og denne driftsmåten kan også være nyttig for å sette opp et bedriftsintranett. Merk at i motsetning til Listen-direktivet (som vil bli diskutert i neste avsnitt), kan bare ett port-direktiv brukes om gangen. For eksempel, for at Apache-serveren skal begynne å lytte på port 4444, må du angi direktivet

5.3.3. Definere en eller flere IP$-porter: Lyttedirektiv

I motsetning til havnedirektivet, overstyrer ikke lyttedirektivet andre lyttedirektiver. For å få Apache-serveren til å lytte på port 80 (HTML-standard) og port (hypotetisk lokal havn), vil vi bruke en rekke direktiver

I tillegg kan Listen-direktivet brukes til å bestemme IP-adresser. La oss anta at eksemplet ovenfor lytter på IP-adressen 192.168.1.2. Følgende lyttekommandoer vil ha en lignende effekt:

Hør 192.168.1.2:80

Lytt 192.168.1.2:

5.3.4. Konfigurere flere IP-porter

To metoder kan foreslås for å støtte flere IP-adresser på ett system:

Kjøp og installer flere grensesnittkort.

I noen operativsystemer For å sette opp overvåking av ett grensesnittkort med flere IP-adresser, kan du bruke ifconf ig-kommandoen.

Det er ganske åpenbart at ideen om å kjøpe mange grensesnittkort ikke trenger kommentarer. Det samme kan ikke sies for bruk av ifconfig-kommandoen. Ifconfig-kommandoen (grensesnittkonfigurasjon) utfører to funksjoner:

Viser konfigurasjonsinformasjon for et eksisterende grensesnitt.

Endre eller legg til informasjon om grensesnittkonfigurasjon.

Den første funksjonen har ubestridelige fordeler, men relaterer seg ikke direkte til serveren. For å gjøre dette, bruk bare ifconfig-kommandoen for å bestemme navnet på det nødvendige kortet.

/home/root> ifconfig eth0

Resultatet vil være følgende svar (selvfølgelig avhengig av systemtype):

eth0 Link encap:Ethernet HWaddr 0 0: 2 0: 7 8: 1 7: 9 A: E B

inet addr:192.168.1.1 Beast:192.168.1.255 maske:255 . 255. 255. 0 OPPSENDING KJØRER MULTICAST MTU:1500 Metrisk:!

RX-pakker:260652 feil:0 droppet:0 overløp:0 ramme:0

TX-pakker:565370 feil:0 droppet:0 overskridelser:0 transportør:0 kollisjoner:0

På den annen side kan ifconfig-kommandoen noen ganger brukes til å gå inn ny informasjon. Her er laget som skaper virtuell enhet eth0:l. Den vil overvåke forskjellige IP-adresser (192.168.100.2).

/home/root> ifconfig eth0:1 192.168.1.2 nettmaske 255 . 255. 255. 0

Hvis konfigurert vellykket, oppfører et h0:1 seg som om det faktisk var der, og svarer på ping og brukerforespørsler som om du faktisk hadde brukt $50 på et nytt kort.

5.4. Delt hosting etter navn

Delt hosting etter navn er relativt ny revisjon HTTP-standard. Med denne metoden er mange forskjellige domenenavn knyttet til en enkelt IP-adresse. Alle domenenavn er registrert og alle forespørsler omdirigeres til samme IP-adresse. Serveren skiller en forespørsel fra en annen ved å bruke HOST-headeren som er konfigurert for hver virtuelle vert konfigurert på serveren.

Dette er uten tvil Bra valg noe reduserte hastigheten på uttømming av Internett-adresseplass. Det eneste problemet er at bare nettlesere som overholder HTTP 1.1-standarden fungerer med HOST-headeren. Derfor vil det være ganske problematisk å få tilgang til slike virtuelle noder ved å bruke utdaterte nettlesere.

Prosessen med å sette opp slik hosting kan deles inn i tre stadier:

Informere DNS om at en eksisterende IP-adresse også er relevant for navnet på den nye virtuelle verten.

Kommuniserer til Apache-serveren hvordan forespørsler rutes til den virtuelle verten.

5.4.1. Domenenavnsystem og navneregistrering

Domain Name System (DNS) er en slags analog av Internetts gule sider. Dette er en distribuert database med IP-adresser og tilhørende domenenavn. Uten domenenavnsystemet eller noe lignende kunne ikke Internett eksistere. Uten en DNS-database er en URL satt i nettleseren helt ubrukelig inntil den tilsvarende IP-adressen er funnet i DNS-databasen.

Gitt det pågående Internett-utvidelse, er det stadig færre gode domenenavn igjen. Alle mulige tre-bokstavs domenenavnkombinasjoner er allerede oppbrukt, så det er ingen grunn til å bekymre deg for dette. De fleste engelske ord er allerede brukt. Forespørsler om nye domenenavn kan sendes til http://www.networksolutions.com (se figur 5.2).

Ris. 5.2. Domenenavnregistrering

Hvis du har Domenenavn som tilfredsstiller deg i alt, så er det verste bak deg. I vanlig praksis til den gjennomsnittlige brukeren Det er slett ikke nødvendig å registrere domenenavnet ditt selv. For de fleste innebærer registrering av en DNS å fylle ut et skjema og sende det til de aktuelle ISP-agentene.

DNS er distribuert database data, dvs. det kan ikke finnes alt på en gang på én server. En brukers forespørsel kan gå gjennom mange servere før en treff blir funnet. Bivirkning er at registreringen av et nytt domenenavn ved verdensomspennende nettverk DNS tar timer, noen ganger til og med dager.

5.5. Sette opp delt hosting etter navn på Apache-serveren

Det er bra at virtuell hosting ved navn er relativt smertefri. For å gjøre dette trenger du bare å gjøre to trinn, selv om det andre ærlig talt kan være vanskelig.

1. Bruk NameVirtualHost-direktivet, finn IP-adressen som skal brukes for virtuell hosting.

2. Bruk et par Vir tualHost-direktiver, velg direktiver som bare vil være relevante for en bestemt virtuell web node.

5.5.1 IP-tilordning for virtuell hosting kalt: NameVirtualHost

Ved å bruke NameVirtualHost-direktivet setter du IP-adressen til den virtuelle verten konfigurasjonsfil httpd.conf. For eksempel et direktiv som

NameVirtualHost 192.168.1.1

vil varsle Apache-serveren om at det er en mulighet for å motta en forespørsel på 192.168.1.22 til andre servere enn standardserveren. For at Apache skal dra nytte av denne informasjonen, må virtualhost-spesifikke direktiver spesifiseres ved hjelp av VirtualHost-parentesene.

Portnummeret kan angis ved å bruke NameVirtualHost-direktivet.

NameVirtualHost 192.168.1.1:80

Virtuell hosting etter navn fungerer bare for nettlesere som overholder HTTP 1.1-standarden eller høyere. Grunnen til dette er at HTTP 1.1-standarden har et HOST-direktiv som spesifiserer vertsnavnet (og porten). Det er her nettleseren henter informasjonen sin. Uten dette direktivet vil ikke serveren kunne bestemme hvilken av Nettnoder kan knyttes til IP-adressen som brukeren ber om.

5.5.2. Starte virtuell hosting: VirtualHost-direktivet

VirtualHost-direktivet er en "brakettoperatør". Den brukes bare i par og begrenser begynnelsen og slutten av direktiver som omhandler virtuell hosting. For å fortsette med eksemplet har vi:

Servernavn www.examplel.org

DocumentRoot/noen/annet/katalog

Vær oppmerksom på at direktiver innenfor parentes , gjelder bare for den virtuelle verten spesifisert av ServerName-direktivet. Direktiv i parentes , kansellerer standardinnstillingene for den IP-adressen. Begrensninger på antall direktiver som kan inneholdes i operatørbraketter , Nei. Men det er visse rimelige grenser (se tabell 5.1).

Tabell 5.1. Direktiver som ikke gjelder for delt hosting

5.5.3. Standard virtuell vert

Bruk nøkkelord _default_ i stedet for en IP-adresse indikerer at konfigurasjonsinformasjonen du angir vil bli brukt som standard i tilfelle innkommende forespørsler ikke kan finne den ønskede virtuelle noden blant eksisterende noder. Du trenger ikke å gjøre dette, men når du først har gjort det, vil du ikke angre. Den nåværende serverkonfigurasjonen kan være så enkel at dette ikke er nødvendig i det hele tatt, men denne standardtilnærmingen kan likevel være ganske nyttig.

Standard direktiver...

5.5.4. IP$adresse eller domenenavn?

Hvis du ser nærmere på kommandoene beskrevet i dette kapittelet (VirtualHost, BindAddress, etc.), vil du legge merke til at mange av dem er utformet for å bestemme domenenavn i stedet for IP-adresser. For eksempel et sett med direktiver

Ulike direktiver...

teknisk korrekt og faktisk mer lesbar enn å bruke en IP-adresse. Dessverre har dette en negativ innvirkning på ytelsen. Når du hoster etter navn, vil Apache-serveren, hver gang den mottar en forespørsel, bli tvunget til å søke fornavn i DNS, og dette bremser arbeidet betydelig.

5.6. Virtuell hosting etter IP$-adresse

IP-basert virtuell hosting forventer ikke at brukernettlesere sender en Host-header (dette gjelder bare for HTTP 1.1-kompatible nettlesere) og kan derfor, avhengig av vertens krav, ikke kreve eksklusivitet. Her er stadiene i den virtuelle vertsprosessen etter IP-adresse:

1. Opprett og registrer et nytt virtuelt vertsnavn.

2. Konfigurere systemet slik at det kan overvåke nye IP-adresser (se avsnittet "IP-adresser og porter" i dette kapittelet).

3. Stille inn DNS-tilkoblingen mellom den nye IP-adressen og vertsnavnet.

4. En melding til Apache-serveren om hvordan man håndterer forespørsler rettet til den virtuelle verten.

De fleste av disse kravene er allerede diskutert. For informasjon om hvordan nye vertsnavn opprettes og registreres, se delen "Delt hosting etter navn" i dette kapittelet. Prosedyren for å lage et nytt navn er lik. Men når du registrerer et nytt virtuelt vertsnavn med bruker DNS du må opprette en ny IP-adresse.

Konfigurering av systemet slik at det kan overvåke nye IP-adresser er diskutert i avsnittet "IP-adresser og porter" tidligere i dette kapittelet.

Hovedforskjellen mellom å konfigurere en Apache-server for virtuell hosting etter navn og virtuell hosting etter IP-adresse er at du i det andre tilfellet ikke trenger å ty til tjenestene til NameVirtualHost-direktivet. For å opprette en node kalt www.example2.com på 192.168.1.2, må du:

Servernavnwww.example2.com

5.6.1.Kombinere virtuelle noder basert på navn og IP-adresser

Det er ingen grunn som kan forhindre kombinasjonen av begge tilnærmingene på ett system. Opprett først all nødvendig virtuell hosting etter adresse, og match deretter adressene for den virtuelle hostingen etter navn. Hvis NameVirtualHost-direktivet har blitt brukt minst én gang på en spesifikk IP-adresse, vil denne adressen allerede gå tapt for den virtuelle hostingen på den adressen.

5.7. Hva du trenger å konfigurere for delt hosting

I alle eksemplene er direktiver satt i parentes med hensikt. Teknisk sett er det slett ikke nødvendig å angi noe i parentes, selv om det er helt meningsløst å spesifisere dem i tilfelle når de ikke inneholder noe. Flere direktiver beskrevet i denne delen kan kalles spesifikke bare for delt hosting.

Når du konfigurerer direktiver, må du huske at virtuelle noder ikke følger egenskapene til Apache-hovedserveren. Den virtuelle vertskonfigurasjonen må overstyre, utvide eller replikere hovedserverkonfigurasjonen.

Som et minimum må du spesifisere et ServerName-direktiv for hver virtuelle node:

Servernavn www. nettsted2. com

Et annet nødvendig element er Docum entRoot-direktivet, som spesifiserer startpunktet for ethvert søk. Jeg tror det i en situasjon hvor for Web-dokumenter en gang personlige kunder separate kataloger er tildelt, vil dette utvilsomt være hensiktsmessig.

DocumentRoot /home/site2

Serve rAdmin-direktivet lar deg spesifisere nøyaktig postadresse administrator for hver virtuelle node. Dette er adressen hvor det vil bli sendt e-post med meldinger om problemer som oppstår under driften av serveren.

ServerAdmin [e-postbeskyttet]

Vi kan også nevne ErrorLog- og TransferLog-filene, siden deres analyse forenkler feilsøking og trafikkanalyse. Det bør imidlertid huskes på det Unix-systemer(inkludert Linux-operativsystemer) pålegger vanligvis en grense for antall filer som individuelle prosesser kan åpne. Å tilordne en separat loggfil til hver virtuelle vert kan raskt overskride denne grensen. Dessverre må jeg be deg konsultere systemdokumentasjonen din for å finne ut hvordan du kan påvirke begrensningene som er pålagt hvert enkelt system. Hvis du har slike mistanker, sjekk systemets syslog-fil. Unix OS er veldig flinke til å fange opp denne typen brudd.