Konfigurera Apache: en steg-för-steg-guide. Apache konfigurationsfiler

16.1. Installera Apache Beroende på din distribution kan paketet som du installerar Apache-webbservern från kallas apache eller httpd, och dokumentationspaketet är apache-docs respektive httpd-manual. I det första fallet måste du installera ett annat apache-common-paket som innehåller

16.2. Konfigurera Apache. Konfigurationsfiler Efter installation av Apache bör du redigera följande filer :? /etc/httpd/conf/httpd.conf är den huvudsakliga konfigurationsfilen. För Apache 2.x. denna fil kan också kallas httpd2.conf ;? /etc/logrotate.d/apache eller /etc/logrotate.d/httpd (i version 2.0) - rotationsfil

16.10. SSL och Apache 16.10.1. SSL-installation SSL (Secure Sockets Layer) är en krypteringsmetod utvecklad av Netscape för att säkerställa säkerheten vid dataöverföring. Denna metod stöder flera krypteringsmetoder och ger autentisering både hos klienten och

19.2. Konfigurationsfiler för starthanteraren Lista 19.1 visar huvudkonfigurationsfilen för GRUB2, /boot/grub/grub.cfg. Den kan inte redigeras manuellt. För att skapa den används verktyget / usr / sbm / grub-mkconfig, som genererar denna konfigurationsfil baserat på mallar,

26.2.3. Serverkonfigurationsfiler Serverkonfigurationsfilerna finns i katalogen / etc / apache2. Huvudkonfigurationsfilen heter apache2.conf. Som standard kommer dess inställningar att passa de flesta användare. Om du planerar att använda webbservern inte bara lokalt (för

Källfiler och körbara filer Vårt underbara program är, trots sin korthet och enkelhet, en helt meningslös uppsättning tecken för en dator, eftersom det "inte förstår" direktiv som #include eller printf. Han förstår bara ett speciellt språk,

5.3.1. Konfigurationsfiler Alla SSH-konfigurationsfiler finns i katalogen / etc / ssh. Här kan du se följande lista: SSH-serverkonfigurationsfil - sshd_config ;? SSH-klientkonfigurationsfil - ssh_config ;? nyckelfiler för olika

Konfigurationsalternativ för kärnfelsökning Det finns flera konfigurationsalternativ som hjälper till vid felsökning och testning av kärnkod, och som ingår vid kompilering. Dessa parametrar är tillgängliga i menyalternativet Kernel hacking i kärnkonfigurationsredigeraren. Alla dessa

Apache är världens mest populära gratis webbserver. Från och med 2016 används den av 33 % av alla sajter på Internet, vilket är cirka 304 miljarder sajter. Denna webbserver utvecklades redan 1995 som en ersättning för den populära NCSA-servern och har åtgärdat många av dess problem. Rykten säger att hans namn kommer från en fläckvis, eftersom han fixade NCSA-buggar. Nu är det ett plattformsoberoende program som stöder Windows, Linux och MacOS och ger tillräcklig flexibilitet, anpassning och funktionalitet. Programmet har en modulär struktur, vilket gör att du kan utöka dess funktionalitet nästan på obestämd tid med hjälp av moduler.

Du kan installera Apache på Linux med några få kommandon, men programmet tillhandahåller ett mycket stort antal inställningar som kan ändras, samt moduler som kommer att få det att fungera bättre efter att det aktiverats. Den här artikeln kommer att täcka installation och konfigurering av Apache, vi kommer att använda Ubuntu som huvudsystem, men du kan upprepa dessa steg i vilken annan distribution som helst. Vi kommer inte bara att överväga installationen av själva programmet, utan också hur man konfigurerar det, konfigurerar virtuella apache-värdar, såväl som de mest användbara modulerna.

För tillfället är den senaste versionen av programmet 2.4, därför kommer det att övervägas att installera apache 2.4. Som sagt, på Linux installeras programmet med bara ett par kommandon. För att installera på Ubuntu, uppdatera först systemet till den senaste versionen:

sudo apt uppdatering
$ sudo apt uppgradering

Installera sedan apache2:

sudo apt installera apache2

I andra distributioner kallas programpaketet antingen so eller httpd, och du kommer inte ha några svårigheter att installera det.

När installationen är klar måste du lägga till webbservern för att starta den för att inte starta den manuellt efter att du har slagit på datorn:

sudo systemctl aktivera apache2

Apache-konfiguration

Tiden har gått när Apache-konfigurationen lagrades i en enda fil. Men det är också korrekt, när allt distribueras i sina egna kataloger är det lättare att navigera i konfigurationsfilerna.

Alla inställningar finns i mappen / etc / apache /:

• Fil /etc/apache2/apache2.conf ansvarig för grundinställningar
• / etc / apache2 / conf-tillgänglig / *- Ytterligare webbserverinställningar
• / etc / apache2 / mods-tillgängliga / *- modulinställningar
• / etc / apache2 / webbplatser-tillgängliga / *- inställningar för virtuella värdar
• /etc/apache2/ports.conf- portarna som apache körs på
• / etc / apache2 / envvars

Som du kan se finns det två mappar för conf, mods och site. Dessa är tillgängliga och aktiverade. När du aktiverar en modul eller värd skapas en symbolisk länk från den tillgängliga mappen till enable-mappen. Därför är det bättre att göra inställningar i de tillgängliga mapparna. Generellt sett skulle man kunna klara sig utan dessa mappar, ta allt och dumpa det i en fil på gammaldags sätt, och allt skulle fungera, men nu gör ingen det.

Låt oss först ta en titt på huvudkonfigurationsfilen:

vi /eta/apache2/apache2.conf

Paus- indikerar hur länge servern kommer att försöka fortsätta den avbrutna överföringen eller mottagningen av data. 160 sekunder borde räcka.

Keepalive på- en mycket användbar parameter, den låter dig överföra flera filer i en anslutning, till exempel inte bara själva html-sidan utan även bilder och css-filer.

MaxKeepAliveRequests 100- det maximala antalet förfrågningar per anslutning, ju fler desto bättre.

KeepAliveTimeout 5- timeout för anslutning, vanligtvis räcker det med 5-10 sekunder för att ladda sidan, så du behöver inte ställa in mer, men du behöver inte bryta anslutningen innan all data är laddad heller.

Användargrupp- användare och grupp, på uppdrag av vilken programmet kommer att fungera.

VärdnamnSökningar- logga domännamn istället för ip-adresser, det är bättre att inaktivera det för att påskynda arbetet.

LogLevel- nivå för felloggning. Standardinställningen är varning, men för att få loggarna att fyllas långsammare, aktivera bara fel

Omfatta- alla include-direktiv är ansvariga för att inkludera konfigurationsfilerna som diskuterats ovan.

Katalogdirektiv är ansvariga för att sätta åtkomsträttigheter till en viss katalog i filsystemet. Syntaxen är så här:

Parametervärde

Följande grundläggande alternativ är tillgängliga här:

Tillåt Åsidosätt- indikerar om .htaccess-filer ska läsas från den här katalogen, det är samma inställningsfiler och samma syntax. Alla - tillåt allt, Inget - läs inte dessa filer.

DocumentRoot- ställer in från vilken mapp du behöver ta dokument för att visa för användaren

alternativ- indikerar vilka funktioner på webbservern som ska tillåtas i denna mapp. Till exempel, Alla - tillåt allt, FollowSymLinks - följ symboliska länkar, Index - visa innehållet i katalogen om det inte finns någon indexfil.

Behöva- ställer in vilka användare som har tillgång till denna katalog. Kräv alla nekade - att förbjuda alla, Kräv alla beviljade - för att tillåta alla. du kan använda användar- eller gruppdirektivet istället för alla för att uttryckligen ange användaren.

Beställa- låter dig kontrollera åtkomsten till katalogen. Accepterar två värden: Tillåt, Neka - tillåt för alla utom de angivna eller Neka, Tillåt - förbjud för alla, förutom de angivna..ru.

Alla dessa direktiv används inte här, eftersom vi är nöjda med standardinställningarna, men i .htaccess-filer kan de vara mycket användbara.

Vi är kvar med filen /etc/apache2/ports.conf:

Den har bara ett direktiv, Lyssna, som talar om för programmet vilken port det ska köras på.

Den sista filen är / etc / apache2 / envvars, som du sannolikt inte kommer att använda, den innehåller variabler som kan användas i andra konfigurationsfiler.

Apache-serverinstallation via htaccess

Htaccess-filer låter dig konfigurera din webbserver på Ubuntu så att den fungerar i en specifik katalog. Alla instruktioner som anges i den här filen exekveras som om de var insvepta i en tagg om de fanns i huvudfilen.

Det är viktigt att notera att för att servern ska kunna läsa instruktioner från .htaccess bör inställningarna för den här mappen i huvudfilen eller den virtuella värdfilen inte innehålla AllowOverride Ingen så att alla inställningar kan fungera som du behöver Tillåt Åsidosätt alla.

När det gäller resten kan valfri konfiguration av apache-servern utföras här, från att aktivera moduler till att ändra åtkomst till en mapp. Eftersom vi redan har övervägt alla parametrar, kommer vi bara att ge ett par exempel:

Beställ neka, tillåt
Förneka från alla

Nekar alla åtkomst till denna mapp, det är viktigt att ansöka om konfigurationsmappar. Oftast används .htaccess för att arbeta med mod_rewrite-modulen, som låter dig ändra förfrågningar i farten:

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

Men detta är ett mycket brett ämne och ligger utanför den här artikelns räckvidd.

Konfigurera Apache-moduler

Som jag sa tidigare är Apache ett modulärt program, dess funktionalitet kan utökas med moduler. Alla tillgängliga moduler, laddare och modulkonfigurationsfiler finns i mappen / etc / apache / mods-available. Och de som är aktiverade i / etc / apache / mods-enable.

Men du behöver inte analysera innehållet i dessa mappar. Konfigurering av Apache 2.4 genom att lägga till moduler görs med hjälp av speciella kommandon. Du kan se alla pågående moduler med kommandot:

Du kan aktivera modulen med kommandot:

sudo a2enmod modulnamn

Och inaktivera:

sudo a2dismod modulnamn

Efter att ha aktiverat eller inaktiverat moduler måste du starta om apache:

sudo systemctl starta om apache2

När ett av dessa kommandon körs skapas eller tas en symbolisk länk till modulfilen med laddningstillägget i den mods-tillgängliga katalogen. Du kan se innehållet i den här filen, det finns bara en rad. Till exempel:

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

Detta beror på att modulen kan aktiveras helt enkelt genom att lägga till den här raden i filen apache2.conf. Men det är vanligt att göra detta för att undvika förvirring.

Modulinställningarna finns i samma mapp, bara i filen med tillägget .conf istället för load. Låt oss till exempel se inställningarna för samma modul för tömningskompression:

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

Filerna i den conf-tillgängliga mappen, dessa är samma moduler, bara de installeras separat från apache, dessa kan vara konfigurationsfiler för att aktivera php-modulen eller något annat programmeringsspråk. Allt fungerar exakt likadant här, bara kommandona för att aktivera och inaktivera dessa moduler är något annorlunda:

a2enconf modulnamn

a2disconf modulnamn

Som du har sett är det väldigt enkelt att aktivera moduler. Låt oss aktivera några moduler som krävs men som inte ingår som standard:

sudo a2enmod löper ut
$ sudo a2enmod headers
$ sudo a2enmod skriva om
$ sudo a2enmod ssl

Modulerna expires och headers minskar belastningen på servern. De returnerar en Ej ändrad rubrik om dokumentet inte har ändrats sedan den senaste begäran. Expiries-modulen låter dig ställa in den tid under vilken webbläsaren ska cache det mottagna dokumentet. Rewrite låter dig ändra de begärda adresserna i farten, mycket användbart när du skapar NC-länkar, etc. Och den sista för att möjliggöra stöd för SSL-kryptering. Glöm inte att starta om apache2 efter att du har slutfört inställningarna.

Konfigurera Apache Virtual Hosts

Det skulle vara obekvämt om bara en webbplats kunde finnas på en fysisk maskin. Apache kan stödja hundratals webbplatser på en enda maskin och tillhandahålla rätt innehåll för var och en. För detta används virtuella värdar. Servern bestämmer vilken domän begäran kommer till och ger önskat innehåll från mappen för denna domän.

Apache-värdinställningar finns i mappen / etc / apache2 / hosts-available /. För att skapa en ny värd behöver du bara skapa en fil med valfritt namn (det är bättre att sluta med värdnamnet) och fylla den med nödvändiga data. Du måste slå in alla dessa parametrar i ett direktiv VirtualHost. Utöver de övervägda parametrarna kommer följande att användas här:

• Server namn- huvuddomännamn
• Serveralias- ytterligare namn som webbplatsen kommer att vara tillgänglig under
• ServerAdmin- administratörs e-post
• DocumentRoot- mapp med dokument för denna domän

Till exempel:

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

Konfigurera Apache

Det finns två sätt att ställa in en webbserver: ändra variablerna som ansvarar för driften av huvudservern, eller skapa en virtuell server. I vårt fall är den andra metoden att föredra. Men mer om det senare, men låt oss nu ta reda på de grundläggande direktiven som styr serverns beteende. Den huvudsakliga Apache-konfigurationen finns i httpd.conf-filen som finns i katalogen:

C: \ usr \ local \ apache \ conf \

Detta är en vanlig textfil, och vilken textredigerare som helst är lämplig för att redigera den - till exempel samma "Anteckningar". Jag kommer inte att gå in i detalj om varje rad i denna fil, utan bara om de mest nödvändiga och nödvändiga direktiven. Observera att "#"-tecknet är en kommentar, och om du kan läsa engelska bra kan du lätt urskilja dem, vilket dock inte hjälper mycket om du inte har åtminstone en allmän förståelse för principerna för driften av Webbservrar och Internet i allmänhet. Så låt mig erbjuda dig min hjälp med att konfigurera Apache. Tillsammans kommer vi att lyckas snabbare och, viktigast av allt, rätt.

Apache-konfigurationsfilen består av tre stora sektioner:

• Global Environment - direktiv som kontrollerar Apache-inställningar i allmänhet;
• Huvudserverkonfiguration - direktiv som styr inställningarna för huvudservern;
• Virtuella värdar - direktiv som styr virtuella servrar.

Vi är inte intresserade av avsnittet med allmänna inställningar, eftersom det är osannolikt att du någonsin kommer att behöva ändra de värden som anges där, men vi kommer att analysera de andra två avsnitten mer detaljerat. Mer exakt, en av dem - jag kommer att prata om användbara direktiv som används vid konfigurering av parametrarna för huvudservern, eftersom samma kommandon används när du konfigurerar virtuella värdar. Den enda skillnaden är att odefinierade parametrar ärvs från inställningarna på huvudservern. Så, låt oss börja...

ServerName är namnet på den webbserver som körs. Den returneras till klienten i ett HTTP-huvud och identifierar webbservern som gjorde begäran. I verklig drift av servern på Internet måste namnet redan existera och vara registrerat i DNS. När du installerar en webbserver lokalt för felsökning och test av webbplatser är detta inte viktigt - namnet kan vara vad som helst. Detta är förresten namnet som installationsprogrammet begärde innan installationen, så om du vill kan du redigera det nu. Parametervärdet måste definieras åtminstone för huvudservern. Annars kommer Apache helt enkelt inte att starta.

ServerAdmin [e-postskyddad]- administratörens e-postadress, som används i några av de automatiskt genererade webbserverfelmeddelandena, till exempel en saknad sida. Parametern måste definieras åtminstone för huvudservern, annars vägrar Apache också att starta.

ServerRoot "c: / usr / local / apache" är katalogen där Apache placerades under installationen. Om du vill flytta den till en annan plats, måste den här raden justeras, precis som alla andra rader i filen som pekar på den här katalogen. Om du installerade Apache som jag beskrev ovan, kommer den här raden redan att vara korrekt konfigurerad och pekar på c: / usr / local / apache.

Port 80 är porten på vilken Apache kommer att lyssna efter HTTP-förfrågningar. Den har som standard standard för webbservrar och kommer sannolikt inte att behöva ändras.

DocumentRoot "c: / usr / local / apache / htdocs" är adressen till katalogen som används för att lagra HTML-sidor. Som standard pekar denna parameter på Apache-dokumentationen som medföljer distributionen och finns i katalogen ovan.

UserDir "c: / usr / local / apache / users /" - katalog som används för att lagra användarsidor, som kommer att vara tillgängliga på:

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

Eftersom vi installerar en webbserver för lokal felsökning av webbplatser, och inte för riktigt arbete på Internet, behöver du inte ändra den här raden.

DirectoryIndex index.html index.htm är en parameter som anger namnet på filen som Apache kommer att leta efter om en ofullständig URL anges. Det vill säga en som slutar med namnet på katalogen, och inte adressen till en specifik sida. Detta gäller även filen som öppnas som standard när du skriver in huvudadressen. Om du till exempel skrev i adressfältet:

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

så kommer faktiskt Apache att öppna en sida:

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

Den fullständiga listan över filer som kan hittas i katalogen definieras exakt av denna parameter. Filnamnen är separerade från varandra med ett mellanslag. Ordningen i vilken de alternativa namnen listas är viktig: om katalogen innehåller filer som heter både index.htm och index.html, kommer Apache att öppna exakt den andra sidan, eftersom index.html listas tidigare än index.htm.

Alias ​​​​/ icons / "c: / usr / local / apache / icons /" - kommandot för att skapa alias, det vill säga länkar, för alla kataloger. Till exempel gör kommandot ovan tillgängligt innehållet i katalogen "c: / usr / local / apache / icons /" på:

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

I det här fallet kan själva katalogen finnas var som helst i filstrukturen och behöver inte vara en underkatalog till en tidigare definierad katalog för att placera HTML-dokument.

ScriptAlias ​​/ cgi-bin / "c: / usr / local / apache / cgi-bin /" - detta kommando liknar det föregående med den enda skillnaden att det bestämmer den verkliga platsen för katalogen med de körda CGI-skripten .

AddType text / html .html .htm är ett kommando som definierar mimetypen för en fil med en given filändelse. I det här fallet ställer vi in ​​tilläggen .html och .htm till en normal hypertexttyp, och Apache kommer att tolka det som html-kod. Mer exakt, webbläsaren måste tolka - webbservern kommer bara att ge den en indikation på att det är hypertext. Men om den här raden inte finns där, kommer Apache att ge sidor med en sådan förlängning som vanliga textfiler.

AddHandler server-parsed .shtml är ett kommando som definierar en hanterare (automatiskt startat program) för en fil med angivet tillägg. I det här fallet länkar vi tillägget .shtml till den inbyggda SSI-direktivhanteraren. Och därför kommer alla filer med detta tillägg, innan de ges sidan till användaren, att genomgå förbearbetning. Mer specifikt kommer Apache att ersätta alla SSI-inlägg med motsvarande värden.

ErrorDocument 404 /error404.html - ett direktiv som definierar en sida som kommer att skickas till användaren när ett fel uppstår. I det här fallet fastställdes sidan för det vanligaste 404-felet. Detta direktiv är valfritt, och om det saknas kommer Apache att generera en standardsida. Men du måste hålla med om att det är mycket mer attraktivt att definiera din egen felsida och dessutom göra den i en enhetlig stil på webbplatsen. Sökvägen till felsidan kan anges antingen lokalt (då måste den nödvändigtvis börja från webbplatsens rot) eller med hela URL-sidan.

ErrorLog logs / error.log - ett kommando som definierar namnet på filen där alla fel som uppstår vid laddning av sidor eller exekvering av CGI-skript kommer att registreras. När du felsöker webbplatser lokalt är detta mycket användbart. Så om något går fel - Apache startar inte, Perl-skript fungerar inte, grafik på sidor laddas inte - den här filen kan hjälpa dig att ta reda på problemet.

CustomLog logs / access.log common - ett direktiv som liknar det tidigare, men med skillnaden att det används för att logga alla förfrågningar till webbservern. Baserat på dess analys kan du få en komplett rapport om webbplatstrafik och populariteten för enskilda sektioner.

Låt oss nu ta en titt på inställningarna för åtkomsträttigheter till filer och kataloger som ingår i strukturen på webbplatsen. Av säkerhetsskäl måste vi ställa in en viss uppsättning rättigheter för alla filer eller kataloger som används för att lagra sidor eller CGI-program. Men först, låt oss titta på hur vi kan ställa in mappen eller filen(er) som vi tilldelar rättigheter. Detta görs med en av följande konstruktioner:

För katalogen:

Alla direktiv som styr katalogåtkomst och alternativ listas här.

För fil(er):

Alla direktiv som styr åtkomst till filen (filerna) listas här.

De obligatoriska värdena ersätts med katalog och filnamn. Det är möjligt att använda reguljära uttryck, vilket gör att du kan ställa in rättigheter för en hel grupp av filer och/eller kataloger.

De rättigheter som definieras för katalogen gäller även för alla underkataloger som ingår i den, såvida inte rättigheterna har åsidosatts för några av underkatalogerna. Nu överväger vi ett sätt att definiera rättigheter i huvudkonfigurationsfilen, men för samma ändamål kan du använda lokala .htaccess-filer, som finns i mappen som du vill begränsa åtkomsten till. I vissa fall är detta mycket bekvämare. Syntaxen för att skriva kommandon i .htaccess-filen är helt lik syntaxen för kommandon i httpd.conf-filen.

Det är viktigt att notera att konfigurering av webbserverbeteende med .htaccess endast är möjligt om det är tillåtet i den överordnade katalogens behörighet. Men jag kommer att säga mer om detta när vi kommer till rätt lag. Under tiden, låt oss börja demontera i ordning alla huvuddirektiv som används för att definiera rättigheter:

• Options option_list är ett direktiv som definierar ytterligare alternativ för en specifik katalog. Alternativen är åtskilda från varandra med mellanslag. De viktigaste är följande:
• Inga - inga ytterligare alternativ definierade för den här katalogen.
• Alla - alla möjliga alternativ är definierade, förutom MultiViews.
• Index - ett alternativ som låter dig använda standardfilerna - med en ofullständig uppsättning adresser. Standardlistan över filer ställs in av DirectoryIndex-direktivet, som beskrevs lite tidigare i den här artikeln. Om det inte finns någon fil i den här katalogen kommer Apache att visa innehållet i katalogen för webbläsaren som standard.
• Inkluderar är ett alternativ relaterat till SSI:s funktion och tillåter användning av Include-direktivet. För att SSI ska fungera fullt ut måste detta alternativ vara aktiverat.
• IncludesNOEXEC - ett alternativ som liknar det föregående, men som förbjuder användningen av SSI-kommandon för att starta ett CGI-skript i includeoch.
• ExecCGI - ett alternativ som tillåter lansering av CGI-program i den här katalogen.
• FollowSymLinks är ett alternativ som låter Apache följa symboliska länkar på UNIX-system. Det vill säga, sidan kan placeras utanför huvudträdet som definierats för lagring av html-dokument.
• AllowOverride är ett direktiv som tillåter åsidosättande av åtkomstparametrar för de underliggande katalogerna. Det jag pratade om tidigare. Detta kommando måste följas av en lista över direktiv som är tillåtna att åsidosätta. Till exempel, AllowOverride All - tillåter åsidosättande av alla rättigheter, AllowOverride Options - tillåter åsidosättande av alternativ för katalogen, AllowOverride None - tillåter inte åsidosättande rättigheter.
• Beställa tillåt, neka - ordningen för att bevilja åtkomsträttigheter till en fil eller katalog från specifika IP-adresser eller domännamn. En mask kan användas för att filtrera bort hela nätverkssegment. I det här fallet bestäms först vilka webbplatser som tillåts åtkomst och sedan till vilka webbplatser som är förbjudna. När det gäller kommandot Order deny är tillåt motsatsen.
• Tillåt från - en lista över IP-adresser eller domännamn från vilka åtkomst är tillåten. En mask kan användas för att ge åtkomst till webbplatsen för en hel grupp av domäner. Till exempel, Tillåt från .com - tillåter åtkomst från alla domäner som slutar på .com. Tillåt från alla - Ger åtkomst till webbplatsen var som helst på Internet.
• Neka från - en lista över IP-adresser eller domännamn från vilka åtkomst nekas. Som i föregående fall kan en grupp av domäner eller en mask av IP-adresser anges.

Dessa är kanske alla huvuddirektiv som används när man konfigurerar Apache. Om du vill veta vad de andra gör, så står allt i din makt - konfigurationsfilen är perfekt kommenterad och med lite flit kan du lista ut det.

Nu när Apache är konfigurerat och körs i en grundläggande konfiguration, och vi är beväpnade med kunskap om de grundläggande direktiven, skadar det inte att lägga till stöd för andra teknologier - i synnerhet SSI. Om du noggrant läser beskrivningen av kommandona för att konfigurera Apache, så har du förmodligen redan gissat att denna SSI-teknik är aktiverad genom att specificera följande två direktiv:

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

Lägg till dessa två rader i avsnittet Dokumenttyp i konfigurationsfilen (eller bara avkommentera dem) och justera standardfillistan genom att lägga till namnet index.shtml där:

DirectoryIndex index.htm index.html index.shtml

Dessutom måste vi för katalogen med dokument definiera rättigheterna att använda SSI-inneslutningar på sidorna. För att göra detta måste du hitta och justera avsnittet som definierar rättigheterna för dokumentets rotkatalog. Det ska se ut så här:

Alternativindex inkluderar AllowOverride All

Inget annat krävs för att stödja SSI-teknik, så låt oss gå vidare till att konfigurera den virtuella servern.

Som jag nämnde tidigare är virtuella servrar bekvämare för att skapa och felsöka webbplatser på den lokala webbservern än att använda inställningarna för huvudwebbservern för detta ändamål. För det första är det väldigt enkelt att lägga till nya virtuella servrar, för det andra finns alla inställningar relaterade till denna server på ett ställe, och för det tredje är det väldigt enkelt att organisera samtidigt stöd för flera projekt.

Men innan du konfigurerar den virtuella servern, låt oss skapa alla nödvändiga kataloger. Jag rekommenderar att du använder katalogstrukturen nedan för internetprojekt. Du kan välja vilken annan enhet som helst som huvudenhet, men jag kommer fortfarande att använda enhet C för förklaringen.

• c: \ web \ - katalog som används för Internet-projekt;
• c: \ web \ project \ - katalog för vårt projekt, som vi kommer att kalla det - project;
• c: \ webb \ projekt \ webbplats \ - webbplatssidor kommer att finnas här;
• c: \ web \ project \ cgi-bin \ - CGI-skript i Perl kan placeras här;
• c: \ web \ project \ logs \ - denna katalog kommer att innehålla webbserverns loggfiler.

Som nämnts ovan åsidosätter direktiv som definieras i den virtuella värdsektionen globala värden. Men först måste du ta reda på hur du definierar själva den virtuella värden. Detta görs med VirtualHost-direktivet med samma namn. Nedan finns ett utdrag som beskriver den virtuella servern för vårt projekt. Lägg till den i slutet av konfigurationsfilen - det är här avsnittet för att definiera virtuella värdar finns. Och sedan ska jag ge detaljerade förklaringar på varje rad:

ServerAdmin [e-postskyddad] Servernamn projekt DocumentRoot “c: / webb / projekt / webbplats” ScriptAlias ​​/ cgi-bin / “c: / web / project / cgi-bin /” ErrorLog c: /web/project/logs/error.log CustomLog c: / web /project/logs/access.log vanligt

Gjord? Bra, låt oss gå vidare till kommentarerna! Så på den första raden definierade jag IP-adressen som kommer att användas för att komma åt den virtuella värden. Eftersom den lokala webbservern är bunden till IP-adressen 127.0.0.1 är det logiskt att virtuella värdar använder följande IP-adresser i ordning: 127.0.0.2, 127.0.0.3, 127.0.0.4, etc.

På den andra och tredje raden omdefinieras administratörens e-post och servernamn. Det är inte nödvändigt att specificera dessa direktiv, men de tillåter oss att mer bekvämt organisera arbetet med webbservern, i synnerhet för att göra det möjligt att komma åt servern inte via IP-adressen utan med värdnamnet som definieras i detta avsnitt, men Jag ska berätta om det lite senare.

Detta följs av en viktig linje som bestämmer platsen för dokumenten för vår webbplats. Inspelningsformatet är helt likt basservern. Alias ​​till CGI-skript och sökvägar till loggfiler har omdefinierats på samma sätt. Lägg märke till att vi använde katalogerna vi skapade några stycken ovan för värdena.

Efter att ha lagt till den virtuella värden måste Apache startas om för att ändringarna ska träda i kraft. Vår virtuella värd kommer nu att finnas tillgänglig på 127.0.0.2. Om något misslyckas och servern vägrar att starta, titta då på vad som står i error.log-filen. Troligtvis kommer det att indikera ett fel i syntaxen för konfigurationsfilen.

Kom ihåg att jag lovade att berätta om hur man gör det så att du också kan referera till servern med namn? Nu har tiden kommit. I konfigurationen av webbservern behöver vi inte längre ändra något, men vi måste justera den interna Windows-filen som bestämmer överensstämmelsen mellan lokala IP-adresser och domännamn. Beroende på vilket system du arbetar med kan den här filen finnas på olika platser eller inte existera alls (i det här fallet måste du skapa den manuellt). Filen kallas värdar och finns i katalogen:

C: \ windows \ - för maskiner med Win9x / Me-system

C: \ windows \ system32 \ drivrutin \ etc \ - för maskiner med WinNT / 2000-system

Den här katalogen kan också innehålla filen hosts.sam (tillägg från ordet exempel - "exempel"), som kan bytas om till värdar om den senare saknas. Hosts-filen är en vanlig ASCII-textfil och har ett mycket enkelt format: varje rad består av en lokal IP-adress och dess motsvarande domännamn. För vårt fall bör den här filen se ut så här:

127.0.0.1 localhost apache 127.0.0.2-projekt

Observera att på första raden har jag definierat två namn för samma IP-adress. Ett anrop till en sådan server är möjligt med vilket som helst av dessa namn. Alternativa namn måste avgränsas med mellanslag.

För att testa vår virtuella server och konfigurerade SSI-teknik måste vi skriva en testsida. För att göra detta, skapa en fil med följande innehåll i valfri textredigerare:

och spara den som index.shtml. Skapa även en test.inc-fil med följande innehåll:

Grattis, SSI fungerar!

Kopiera båda filerna till katalogen c: \ web \ project \ website \, som är konfigurerad som katalogen för våra projektdokument, och skriv i adressfältet i din webbläsare:

Http: // projekt /

Om du ser gratulationer i webbläsaren är allt i sin ordning: SSI fungerar, och dessutom fungerar det nya standardtillägget, index.shtml. Om något inte fungerar korrekt för dig, läs om de sista styckena noggrant och se till att du gjorde allt korrekt.

Apache är installerat och konfigurerat - fortsätt till att installera och konfigurera PHP.

Installera PHP4 på Windows

Vi kommer att installera den senaste PHP-versionen som är tillgänglig när detta skrivs, nämligen PHP4.0.4pl1. Adressen där du kan ladda ner den anges i slutet av denna artikel. Arkivet med denna PHP-distribution finns också på CD:n som bifogas tidningen.

Distributionspaketet är ett vanligt ZIP-arkiv, och det räcker för att packa upp det i önskad mapp. Följ samma överväganden som jag gav när jag skapade katalogen för Apache-installationen, packa upp PHP-distributionen i en mapp:

C: \ usr \ local \ php4 \

Byt till den angivna katalogen, hitta filen php.ini-dist där och, byt namn på den till php.ini, kopiera den till Windows rotkatalog (vanligtvis c: \ windows). Den här filen innehåller alla inställningar som styr PHPs beteende och är en vanlig textfil. Eftersom standardkonfigurationen är bra för oss finns det för närvarande inget behov av att fixa något i den här filen.

Nu måste du konfigurera Apache och PHP för att fungera tillsammans. Det finns två huvudsakliga sätt att installera PHP - som ett vanligt CGI-program och som en Apache-modul. Vi ska titta på båda och börja med att konfigurera PHP som ett vanligt CGI-program.

Installera PHP som ett CGI-program

Det huvudsakliga konfigurationsarbetet måste göras på Apache-konfigurationsfilen. Om du redan har stängt filen httpd.conf, öppna den igen och lägg till några rader relaterade till PHPs funktion där. Först måste vi definiera en ny filtyp och mappa den till tilläggen som används av PHP. För att göra detta, lägg till följande rad i avsnittet "Dokumenttyper":

Nu måste du tilldela en hanterare för denna filtyp, så lägg till följande utdrag direkt efter typdefinitionen:

Alternativ ExecCGI

Slutligen lägger vi till index.php-värdet till listan över indexfiler. För att göra detta, hitta och korrigera följande rad:

Alla nödvändiga PHP-inställningar har gjorts, och du kan testa funktionaliteten hos PHP. För att göra detta, skapa en testfil med följande innehåll:

och spara den som test.php i katalogen c: \ web \ project \ website \, som vi tidigare definierat för att lagra vårt projekts HTML-filer. Nu, genom att skriva raden i webbläsaren:

Http: //project/test.php

Http://127.0.0.2/test.php,

vi borde se hälsningstexten. Om allt är i sin ordning kan du slutföra konfigureringen av PHP. Om inte, kontrollera noggrant de direktiv som beskrivs ovan i filen httpd.conf. Glöm inte heller att starta om Apache innan du kontrollerar.

Att installera PHP som ett vanligt CGI-program är ganska enkelt, men det tillåter oss inte att använda vissa av funktionerna relaterade till användarbehörighet, permanent anslutning till databaser och ett antal andra funktioner. Därför kommer vi nu att analysera den föredragna installationsmetoden - som en Apache-modul. Denna metod ger märkbart snabbare prestanda på grund av frånvaron av overhead för att köra ett externt CGI-program. Men för vårt fall - att använda en lokal webbserver för att testa webbplatser - är exekveringshastigheten inte kritisk.

Installera PHP som en Apache-modul

Det första vi behöver göra är att hitta en kompilerad PHP-modul för att ansluta den till Apache. Om du installerade PHP som jag beskrev tidigare, så finns filen vi behöver på:

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

Kopiera denna fil upp en nivå till PHP-huvudkatalogen:

C: \ usr \ local \ php4 \

Nu måste vi ställa in några variabler i Apache-konfigurationsfilen. Som med att installera PHP som ett CGI-program, måste du lägga till en ny dokumenttypsdefinition i avsnittet Dokumenttyper:

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

Och korrigera även raden som innehåller listan med indexfiler:

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

Nu är det viktigaste att konfigurera laddningen av modulen. Hitta avsnittet "Dynamic Shared Object (DSO) Support" i konfigurationsfilen och lägg till följande rad i den:

LoadModule php4_module "från: /usr/local/php4/php4apache.dll"

Konfigurationen kan anses vara komplett. Det återstår bara att testa PHP-funktionaliteten. Kom bara ihåg att spara filen först och starta om Apache. För testning kan du använda det tidigare skrivna test.php-skriptet. Skriv raden i webbläsaren:

Http: //project/test.php

och se till att PHP körs framgångsrikt. Om något är fel, kontrollera noggrant noggrannheten av sökvägarna till modulen du angav och dess faktiska plats i den angivna katalogen.

Och en liten notering för de som redan har konfigurerat PHP som ett CGI-program och nu försöker installera det som en modul, glöm inte att ta bort avsnittet som kopplar samman filtypshanteraren med CGI-programmet från Apache-konfigurationsfilen. I det här fallet är den externa modulen redan engagerad i all bearbetning av php-filer. Jag menar detta utdrag:

ScriptAlias ​​"/ __ php_dir __ /" "c: / usr / local / php4 /" Action application / x-httpd-php "/__php_dir__/php.exe" Alternativ ExecCGI

Det är här vi avslutar vår artikel och lämnar beskrivningen av de viktigaste PHP-konstruktionerna till nästa gång. Jag är av uppfattningen att det är lättare att lära av verkliga exempel, och inte från abstrakta konstruktioner, så nästa gång kommer vi att kombinera affärer med nöje och, studera PHP-konstruktioner, kommer vi att skriva ett fullt fungerande manus - en gästbok.

ComputerPress 7 "2001

Professionell utveckling fokuserar alltid på sina egna verktyg - detta är en garanti för tillförlitlig och effektiv fullgörande av skyldigheter. Egna hosting och servrar för olika ändamål i utbudet av efterfrågade konfigurationer utökar omfattningen av uppgifter som ska lösas, ökar säkerheten och sekretessen för utvecklingen.

Native HTTP: Apache, PHP, MySQL

Apache webbserver har varit en stark ledare sedan förra seklet eftersom den ger snabb, pålitlig och säker drift. En fysisk maskin och server som kör Linux eller Windows är grunden, HTTP är ett tillägg, även om det i huvudsak är ett dataöverföringsprotokoll. En Windows-maskin kan användas som server, men Linux-familjen är att föredra.

Apache på Windows är en lokal version som används på en enda maskin för att duplicera utvecklingsresurser på externa servrar. Inställning på är acceptabelt, men inte särskilt populärt. Att konfigurera Apache på CentOs ger fler alternativ och används för att organisera servrar i lokala och globala nätverk.

Man tror att Apache-servrar tjänar mer än 50% av alla aktiva webbresurser, resten står för liknande produkter från Microsoft, Sun, etc. Egentligen kan en fysisk server och dess operativsystem vara vad som helst. HTTP-servern är installerad på en färdig plattform och fungerar parallellt med andra applikationer på den. Apache anses vara inbyggt i hela Linux-familjen, men i varje fall har den sina egna särdrag.

Frihet, enkelhet, tillförlitlighet särskiljer Linux-system och deras applikationer. Det spelar ingen roll vilken du använder: att installera och konfigurera Apache på Ubuntu skiljer sig inte mycket från CentOs, Debian eller FreeBSD. Mättnaden av ett visst operativsystem med ytterligare programvara spelar ofta en roll.

Linux-familjen är liten när det gäller antalet "släktingar" på raden av en eller annan kärna i systemet. Skillnaderna är mer sociala till sin natur - i betydelsen av utvecklarnas fäste vid formuleringen och implementeringen av operativsystemets kapacitet.

I verkligheten, för att lösa en specifik uppgift för att höja hosting, är det nödvändigt att besluta om den nödvändiga funktionaliteten, den erforderliga prestandan, konceptuella prioriteringar och ett specifikt val av en Linux-representant, eller välja Windows Server.

Förskjuta prioriteringarna för lokal utveckling

Det är svårt att bedöma det globala nätverkets roll i utvecklingen av programmering, men det är lätt att märka det verkliga skiftet i tyngdpunkten: lokala applikationer började köras som en webbresurs. Skriv bara ett program för en lokal dator - dessa är drivrutiner, antivirus, små projekt med enkel funktionalitet. Programmeringsspråket ... VBA, även om du kan använda C / C ++ eller C #.

Varje informationsprojekt är en webbresurs i företagets lokala nätverk, som delvis kan vara tillgänglig från det globala nätverket, till exempel för att samordna de anställdas handlingar utanför kontoret på vägen eller på en affärsresa.

MySQL, PHP, Apache: att ställa in för ett lokalt användningsfall är en helt annan dynamik i applikationen, den nödvändiga funktionaliteten. Moderna företag, oavsett storlek, antal anställda och verksamhetsområde, överväger allvarligt internetprogrammering, både lokalt och globalt.

I det här fallet kan det lokala distribueras: företagets kontor kan finnas var som helst, men det här är inte Internet, utan ett distribuerat lokalt nätverk av företaget.

MySQL, PHP, Apache-inställning i lokal form:

• lätt duplicerad över nätverksdatorer;
• ger möjlighet att dynamiskt ändra den aktiva komponenten eller jämföra den med ett prov för att utvärdera hackningsförsök;
• ger anledning att utveckla ett säkerhetssystem som är fri från risken att attackeras av klassiska nätverksmetoder.

Med tanke på att MySQL och Apache är tjänster på Windows, och PHP-kod är ren text som bearbetas av ett verktyg (PHP-tolk) som anropas vid rätt tidpunkt av en HTTP-server, då kommer nivån av mutabilitet, portabilitet och portabilitet för koden att vara mycket högre än lokala utvecklingsverktyg.

Förbereder för att installera Apache

Tillbaka i de tidiga dagarna definierade Unix-operativsystemet de outtalade principerna för lojalitet. Sedan dess har allt som gjordes för Unix-liknande system automatiskt översatts till andra plattformar. Att konfigurera Apache på Windows är enkelt, men seriösa uppgifter kräver en hel del skicklighet och detaljerad förståelse för HTTP-serverkonfigurationen.

Först och främst måste du ladda ner den senaste versionen av servern (idag är det version 2.4.33 daterad 03/17/2018) från den officiella webbplatsen i zip-arkivformat. Man bör inledningsvis komma ihåg att serverversionerna är många och erbjuds på många tredjepartsresurser, så det är viktigt att välja en officiell implementering på en pålitlig webbresurs.

Tidigare var det populärt att installera en server med ett speciellt installationsprogram. Det är nu vanligt att helt enkelt distribuera ett zip-arkiv. Det är enklare och gör det möjligt att förstå kärnan i konfigurationsprocessen, vilket är mycket viktigt och sedan låter dig optimera servern för den belastning och funktion som krävs.

Redigera konfigurationsfilen

Serverkonfigurationen bestäms av en uppsättning konfigurationsfiler som finns i conf-mappen. Den huvudsakliga Apache-konfigurationsfilen är httpd.conf.

I den överväldigande majoriteten av fallen är det nödvändigt att göra ändringar i huvudfilen för att förtydliga innehållet i filerna som ansvarar för ssl och virtuella värdar. Resten av inställningarna görs vanligtvis i processen när problem uppstår eller uppgifter löses. I grund och botten är ytterligare inställningar relaterade till optimeringen av Apache eller utbyggnaden av dess kapacitet.

För att framgångsrikt starta servern räcker det att endast redigera en rad (i ordning - 38:e) - och Apache-konfigurationen är klar.

I de tidigare versionerna av serverkonfigurationen krävdes det att göra många redigeringar för den verkliga situationen, men nu finns det en "universell" variabel SRVROOT. Det är värt att ange dess korrekta värde (sökvägen till serverplatsen), och allt kommer att fungera direkt.

Procedur för servervärd

Platsen för servern måste noggrant övervägas. Apache i sig är intressant, men när den är utrustad med PHP och MySQL är den dubbelt intressant. Det är bättre när allt som rör webbutveckling finns på ett ställe. Du kan gå med på standardvägarna, men modern programmering är inte så idealisk i sin implementering, så du måste hålla fingret på pulsen entydigt och ofta. Dessutom, när du väljer en lämplig plats, kommer alla initialiserings- och konfigurationsfiler, såväl som loggar om driften av installerade produkter, att vara tillgängliga.

Den nedladdade Apache officiella zip-filen bör distribueras till den plats du väljer, och separera verktyget och arbetet. I det här exemplet är mappen C: \ SCiA ett verktyg (Apache24, PHP, MySQL, ...), och mappen SCiB är i själva verket arbetet med webbplatser som skapas, underhålls eller uppgraderas.

Som ett resultat av det första steget av arbetet kommer endast undermapparna bin, cgi-bin, conf, error, ... med allt innehåll in i mappen C: \ SCiA \ Apache24.

Redigera hosts-filen

Det andra steget är att korrekt konfigurera hosts-filen - en indikation på vilka IP-adresser på en given dator som är mappade till vilka namn. Om bara en webbplats kommer att utvecklas eller underhållas på en dator, kan ingenting ändras.

Bas IP - 127.0.0.1 pekar vanligtvis alltid på localhost. Värdens arbetsfil finns på c: \ Windows \ System32 \ drivrutiner \ etc och ser ut som nedan.

För att placera hosts-filen på rätt plats måste du använda kommandoraden i administratörsläge. Du kan förbereda det korrekta innehållet i filen var som helst i din dators filsystem, men du kan bara skriva det till adressen c: \ Windows \ System32 \ drivrutiner \ etc med ett verktyg som har administratörsrättigheter. Det enklaste sättet att göra detta är genom kommandoraden.

Installera Apache Server

Det kunde inte vara lättare. Det räcker att köra kommandoraden som administratör och gå till mappen C: \ SCiA \ Apache24. Eftersom detta är en Windows-sökväg används snedstreck framåt. I ett specifikt fall kan vägen vara annorlunda. Men om du på något sätt kan experimentera med namnet på mappen för platsen för den heliga treenigheten - Apache, PHP och MySQL, då är det opraktiskt att ändra mappnamnen för var och en av dem.

I det här fallet är serverarkivet distribuerat i mappen C: / SCiA / Apache24, därför måste du skriva kommandot i bin-mappen:

• httpd.exe -k installation

Servern kommer att testa konfigurationsfilen och installera sig själv. Troligtvis kommer det att finnas mindre fel, men om du redigerar konfigurationsfilen korrekt, kommer alla fel att vara mindre och kan snabbt åtgärdas.

Fönster (1) kommandorad - tjänstinstallation, fönster (2) - lista över tjänster där servern dök upp, fönster (3) - källfil index.html, som finns på C: / SCiB / localhost / www, fönster (4) - resultatet av servern.

I det här exemplet gjordes ett misstag medvetet: istället för att ställa in värdet på SRVROOT-variabeln, gjordes många redigeringar "på gammaldags sätt": allt ändrades manuellt. Detta är inte den bästa lösningen. Innan du tillämpar kunskap bör du bekanta dig med den aktuella versionen av produkten. Som regel förändras saker snabbt och kunskap bör tillämpas "med kunskap och förståelse för nuläget."

Användning av zip-filer

Moderna sajter skrivs inte alltid på platshanteringssystem. Det är mycket manuellt arbete. Problemet med att överföra webbplatsen till ett annat webbhotell ledde till en bra lösning - ett zip-arkiv. Komprimerat innehåll på ett ställe, utplacerat - på ett annat.

Att ha en installatör är en bra praxis, men dynamiken i modern informationsteknik ger inte tid att skriva vackra installationer. Att installera via zip-distribution är modernt, praktiskt och bekvämt. I det här fallet är Apache-konfigurationen begränsad till att ändra konfigurationsfilerna.

När du installerar servern är det viktigt att ange:

• Var befinner han sig;
• var är webbresursen (localhost);
• använder ssl;
• virtuella värdar.

Den sista positionen är relevant när den ska utveckla eller underhålla flera resurser på servern samtidigt. För en riktig utvecklare är detta ett måste-ha-beslut: även om han tillhandahåller driften av en webbplats kommer det inte att vara överflödigt att ha en reserv.

Gentlemen's set

Lättheten att distribuera zip-arkivet är uppenbart, Apache (installation och konfiguration) är bara två till tre klick. Men resultatet när installatörer var populära var likvärdigt. Utvecklaren ägnade helt enkelt mer tid åt att utveckla nästa version av sin produkt. Att installera en server, serverspråk och databas är i huvudsak bara ett gäng filer, starttjänster, en värdfil och standardsökvägar i operativsystemets variabelsökväg.

Utseendet på Denver och liknande gentlemen's kits av utvecklaren var ett revolutionerande steg i riktning mot enkelhet och bekvämlighet, men gör inga misstag. Revolution och programmering är absolut oförenliga saker. Den första är ett barn av konflikten och dess stormiga lösning, den andra är en allvarlig fråga som kräver absolut lugn, punktlighet, noggrannhet, konsekvens, uppmärksamhet, säkerhet, pålitlighet.

Att konfigurera Apache-servern är en allvarlig procedur som måste tas mycket noggrant och allt bör göras så att du imorgon kan ändra och förtydliga något.

I de flesta fall är utvecklingen av webbresurser en ganska lång process där kraven på tjänster (Apache, PHP, MySQL, ...) ändras snabbt, men det finns alltid tid att förstå nästa uppgift och dess optimala lösning. Men detta är inte en anledning att gå om herrarnas uppsättningar. Tiden går, men gentlemannen förändras inte, detta är ett mycket tyngre argument än Denver-deklarationen – det är enkelt, snabbt och prisvärt.

Flera sajter - en server

Att konfigurera Apache 2.4 för en enda värd är en onödig lyx. Trots sin kompakta design bär denna server ett enormt ansvar för mer än hälften av de aktiva webbresurserna på Internet. Dessutom har inte alla resurser en representativ del och är synliga i nätverket.

Servern kan användas som en databas, som en informationsöverföringspunkt, som ett filter, som en parser, som en arbetsmekanism i en mer global informationsprocess. Som ett resultat krävs nästan alltid konfiguration av Apaches virtuella värdar.

En server kan stödja så många webbresurser du vill, för detta måste du ta bort kommentaren från rad 501 i filen httpd.conf:

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

och beskriv alla nödvändiga värdar i en fil

• extra \ httpd-vhosts.conf.

Det kan vara nödvändigt att klargöra vilka portar och IP servern lyssnar på, men detta är ett separat ämne, för första gången kan du begränsa dig till vad som är.

Det bör noteras att i exemplet, för att underlätta beskrivningen av verkliga virtuella webbresurser (och det finns många av dem), introduceras variabeln (DOCROOT) med sökvägen till den delade mappen för alla webbresurser som är tillgängliga via den installerade servern .

Apache SSL-konfiguration är tillgänglig på liknande sätt. I httpd.conf-filen behöver du bara lämna "som är" raderna 524 till 531, som är ansvariga för driften av SSL.

Enkelheten och komplexiteten i Apache

Dagarna när det var riktigt svårt att sätta upp en server är sedan länge förbi. Att konfigurera Apache idag är en mycket enkel procedur som inte kräver några speciella färdigheter från utvecklaren.

Tre enkla steg:

• utöka arkivet;
• ändra konfigurationsfilen;
• installera servern.

Som ett resultat är Apache fullt fungerande. Om du inte tar hänsyn till krångligheterna i serverdriften vid maximal belastning eller utför lokal utveckling på en Windows-dator, krävs inte ytterligare kunskap.

Svårigheter kan uppstå på Linux-system. Betydligt olika förståelse för filsystemet, användar- och grupprättigheter, samt organisationen av processen för interaktion med andra applikationer kräver att en utvecklare har större kompetens och förståelse för hur Linux-datorer fungerar.

Att konfigurera Apache på vilket Linux-system som helst öppnar mycket fler möjligheter för utvecklaren och ger tillgång till det lokala nätverket och Internet. Traditionellt är en Windows-dator en lokal arbetsstation med en intern server. Linux-dator - och en lokal nätverksnod eller punkt i internetutrymmet.

Professionell utvecklingsmiljö

Apache är en grundläggande byggsten i internetutrymmet som enkelt kan konfigureras, användas och ryggraden i ett företag.

Denna logik förutsätter närvaron av minst en server i nätverket på CentOS, Ubuntu, FreeBSD, Windows arbetsstationer. Det är optimalt att ha två Linux-servrar (primär och sekundär), Apache-konfiguration för en lokal dator i Windows-miljö. I händelse av en virusattack eller en oförutsedd situation kommer hjälpservern att ersätta den huvudsakliga, och den viktigaste - för reparation och återställning. Du kan ersätta den lokala Apache-installationen på en arbetsstation (under Windows) från arkivet.

Denna triviala lösning kan förfinas och kompletteras i praktiken. Storleken på företagets informationsflöden kan avgöra den önskade konfigurationen och det erforderliga antalet servrar. Egentligen är Apache designad för att fungera under belastning, men ingenting hindrar dig från att fördela ansvaret för en server över flera. En lösning som tar hänsyn till det specifika för ett visst företag är alltid mer lovande än att anpassa ett tredjepartsalternativ.