AJUDA SOBRE APACHE

01 Què és Apache?

02 Com es comporta Apache en relació a proves comparatives amb altres servidors web?

03 On es pot trobar tota la informació sobre Apache?

04 Existeix una versió d'Apache per Windows32?

05 Com es comporta Apache en Win32?

06  Per què precisament Apache amb tots els servidors web que es troben en circulació?

07 Per a què pot servir-me Apache si no tinc una xarxa d'ordinadors? 

08 Què cal fer per configurar Apache? 

09 Hi ha tools de configuració gràfica per a Apache?

10  Vist el vist, ¿es distribueix Apache amb una documentació exhaustiva?

11  Què fer en cas de problemes?

12  Com es resolen els problemes amb els CGI en cas d'errors del servidor?

13  És possible que Apache executi els scripts en directoris diferents de cgi-bin?

14  El directori cgi-bin té alguna cosa de diferent respecte a altres directoris?

15  És possible que Apache executi tots els arxius amb extensió .cgi?

16  Què significa SSI?

17  Què és l'arxiu .htaccess i per a què serveix?

18  El nom d'usuari i la contrasenya de què s'ha parlat, estan ocults al públic?

19  Apache suporta SSL?

20  Què significa donar-li a la pròpia màquina sobre la qual funciona Apache 1 domain name? 

21  Com es programa un domain name?

22  Però a mi no em serveix tenir un domain name; la meva màquina només és per a ús domèstic ...

23  Què són els mòduls?

24  Com es carreguen els mòduls?

25  Quina és la diferència entre ServerRoor i DocumentRoot?

26  Puc fer servir el mateix directori com ServerRoot i com DocumentRoot?

27  Què són els host virtuals? 

28  Quins són els avantatges dels virtualhosts? 

29  Com es configura Apache per als VH? 

30  Puc contribuir al projecte Apache? 

 

 

 

1. Què és Apache?

 

Apache, substancialment, és un projecte nascut per crear un servidor de web estable, fiable i veloç per a plataformes Unix. Apache neix, per una banda, d'un codi ja existent i d'una sèrie de patch per millorar la seva fiabilitat i les seves característiques; d'aquí el seu nom: A Patchy server! L'equip de desenvolupament, a més, està format per voluntaris, disseminats per tot el món, que segueix mantenint aquest servidor de web lliure. 

 

 

2. Com es comporta Apache en relació a les proves comparatives amb altres servidors de la web?


'Les proves depenen molt de com s'efectuen i sobretot de per qui! Les estadístiques més fiables semblen les que es refereixen a 
http://webcompare.internet.com/chart.html . 
Apache es demostra més ràpid que altres webserver free;alguns webserver comercials, però, sembla que són més veloços que Apache, però aquí entra en joc el discurs anterior a propòsit de "Qui fa els benchmark": cada un intenta sempre portar l'aigua al seu paella. 
En qualsevol cas, no és una casualitat que Apache sigui el webserver més difós en la gran xarxa (es parla, aproximadament, de 1.500.000 server; feu la prova veient
http://www.apache.org/info/apache_users.html ). 

 

 

3. On es pot trobar tota la informació sobre Apache?


Fonamentalment en www.apache.org; existeix també una publicació electrònica que es diu "Apache Week", i que es llegeix en línia en la direcció 
http://www.apacheweek.com/ ;finalment, es pot trobar una discreta quantitat de llibres sobre l'assumpte; per informar-vos, busqueu enhttp://www.apache.org/info/apache_books.html ; per desgràcia, la major part dels llibres és en anglès, encara que es troben algunes traduccions (vegeu www.jacksonlibri.com). 

 

 

4. Existeix una versió d'Apache per Windows32?


És clar que sí. Apache neix originàriament en sistemes Unix, però s'han fet numeros porting per al seu ús en diferents plataformes. Tant per a més informació com per descarregar la versió per a Windows32, vegeu 
http://www.apache.org 

 

 

5. Com es comporta Apache en Win32?


En substància, la versió per a Windows és in "advanced beta", no tant per l'escassa estabilitat del codi com per la dificultat d'porting en una plataforma gairebé totalment diferent de Unix. A més, les versions de Windows no suporten, o suporten de forma diferent, algunes característiques dels sistemes Unix, fent que es ressenti l'esmentat porting: algunes característiques, de fet, no estan presents en les actuals versions per a Windows, si bé l'equip espera poder-reimplantar en releases futurs. 

 

 

6. Per què precisament Apache amb tots els servidors de web que es troben en circulació?


Sobretot per qüestió de gustos, però no només per això.Molts dels servidors de web que es poden trobar són comercials i, per això mateix, més adequats per a usuaris professionals que poden permetre inversions en aquest sentit; a més, un programari professional no és a priori millor que un lliure: és més, de vegades passa just al contrari. 
Una altra raó per preferir Apache és la gran difusió en els servidors web, impecable targeta de visita que garanteix rendiment i estabilitat. I a més Apache és un projecte, i com a projecte, està obert a les crítiques, patches i bugfixes suggerits directament pels seus usuaris, que poden entrar a formar part de l'equip de desenvolupament; així mateix, la possibilitat de comptar amb un programari amb tantes fonts és una cosa digne de tenir-se en compte. En darrer terme, depèn del sistema en què se li ha de fer treballar: en els Unix, Apache és probablement la millor elecció; en els sistemes Windows, però, sembla més convenient, almenys de moment, dirigir-se a IIS, donada la completa integració amb el sistema (es parla sempre d'instruments signats per Microsoft). 

 

 

7. Per a què pot servir-me Apache si no tinc una xarxa d'ordinadors?


Pot servir per a més d'una cosa: el primer, per practicar amb aquest instrument: qui sap, és possible que un dia o altre us pugui ser útil el que un dia heu après a casa per a un treball.

 
A més, per al qual és aficionat a programmare script CGI o per a qui hagi de testar scripts abans d'instal·lar-los en el seu servidor remot: millor perdre una mica de temps en el vostre sistema local, que estar connectat a la xarxa intentant entendre per què un script no es posa a funcionar.


En definitiva , fins i tot sense una xarxa de Pc, Apache pot ser-vos útil. 

 

 

8. Què cal fer per configurar Apache?


Apache es basa fonamentalment en dos arxius, httpd.conf i srm.conf, presents a la RootDir (veure més) del servidor.Després, per a una configuració més precisa, es poden crear ad hoc arxius que determinin directoris, de manera que Apache actuï en conseqüència una vegada que llegeixi les informacions que trobi en ells.


D'aquesta manera, serà possible donar-li al servidor de web una configuració base i un directori personalitzat per directoris. 

 

 

9. Hi ha tools de configuració gràfica per a Apache?


S'ha fet algun intent, però el millor és sempre modificar a mà els arxius de configuració, el ​​món Unix, i encara no manca d'una interfície gràfica d'usuari, ha nascut amb una línia d'instrucció, i és precisament amb aquesta amb la que s'obtenen els millors resultats. Al Windows, haurem de comptar amb un editor de textos per configurar Apache.

 
Si tot això us desmoralitza, mentrestant proveu i dins d'alguns mesos potser us adoneu que coneixeu Apache millor que si ho haguéssiu configurat amb un tool gràfic, com succeeix amb la majoria dels programes. 

 

 

10. Vist el vist, ¿es distribueix Apache amb una documentació exhaustiva? 


Per descomptat, l'equip Apache s'acosta als usuaris també en això, mantenint la documentació al dia al nostre lloc web, i dotant a cada instal·lació amb un manual d'aproximadament 1.5Mb, que potser no serveixi per desvetllar tots els secrets del servidor de xarxa, però sí us ajudarà en la seva configuració. 

 

 

11. Què fer en cas que hi hagi problemes?


La resposta a una pregunta tan general és simple: Apache crea arxius de log detallats, sempre que es triï una bona profunditat de logging: llegir aquests fitxers pot ser molt útil per resoldre els problemes més comuns, com per exemple script que no es poden executar , problemes amb els permisos, etc. 

 

 

12. Com es resolen els problemes amb els CGI en cas que hi hagi errors del servidor?


En general, el servidor no és mai culpable si no s'executen els script CGI: sovint, però, és l'usuari qui oblida alguns particulars que impedeixen l'execució correcta d'aquests script. Per tant, també la pàgina amb "Server error" probablement es refereix més a l'script en si que al servidor de web.

 

No obstant això, no es pot excloure a priori que el servidor no sigui el responsable: errors en la col·locació del directori que conté els script, falta de mòduls que impossibilita l'execució dels script poden ser problemes imputables a la incorrecta execució dels script.

 

 

 

13. Es pot aconseguir que Apache executi els script en directoris diferents del cgi-bin?


Fer això és absolutament possible a través de la disposició ScriptAlias, la sintaxi és: ScriptAlias ​​url-path directory on en "url-path" heu de substituir el url pel directori i en el "directory" pel corresponent directori local. Per exemple, si el directori local "/var/cgi-bin" voleu que es correspongui amb el directori cgi-bin, haureu d'escriure: ScriptAlias ​​/cgi-bin//var/cgi-bin/

 

 

14. ¿El directori cgi-bin és diferent respecte a altres directoris?


Podem dir que sí i que no.

 
"No", físicament, perquè es pot cancel·lar i tornar a crear sense problemes amb "rmdir" i "mkdir" (excepte, òbviament, els arxius que aquesta conté); "Sí", pel que fa al "paper" que exerceix en el sistema en relació amb el servidor de web: al cgi-bin, normalment estan inclosos tots els arxius, els quals s'han d'executar tot i que no es mostrin directament; res impedeix, de totes maneres, que el cgi-bin es digui "script" o "Mario", sempre que en ScriptAlias ​​(a l'arxiu httpd.conf) es el convoqui amb el nom que s'hagi triat.


A manera de conclusió, el cgi-bin és un directori normalíssim que a través del resvidor de web es converteix en un directori especial.

 

 

 

15. És, però, possible fer que s'executin en Apache tots els fitxers amb extensió .cgi?


Per descomptat, sempre que el directori en què resideixin aquests arxius estiguin al DocumentRoot del servits. Perquè Apache els executi, poi, n'hi haurà prou amb utilitzar la directiva AddHandler, la sintaxi és: AddHandler handler-name extension extension .. Per exemple, perquè s'executin a Apache tots els arxius amb sufix .cgi caldrà escriure:AddHandler CGI- scripts cgi Vegeu, en tot cas, que és possible especificar més d'un sufix, de manera que, per exemple, es pot afegir .pl perquè Apache executi també els script amb sufix .pl. 

 

 

16. Què vol dir SSI?


SSI significa Server-Side Include, que no són sinó directives que permeten que l'HTML estàtic sigui "interpretat" immediatament per donar determinats output al browser de qui ho estigui demanant. La interpretació "on the fly" dels SSI es defineix com "parsing": aquest parsing és molt garrepa que fa a les peticions, i no ofereix informacions per defecte.Per a un exemple, un SSI és una cosa així com: <! - # exec cgi = "cgi-bin/nomescript.cgi" -> Incloent aquesta línia en el codi HTML d'una pàgina html normal, i habilitant el parsing, precisament en el punt en què està present, es podrà veure l'output de l'script. Això és interessant per dos motius:

 

 

17. Què és l'arxiu .htaccess i per a què serveix?


L'arxiu .htaccess és un simple arxiu de text que Apache fa servir per tenir algunes regles sobre els directoris i els fitxers.Resumint, aquest conté determinades directives que obliguen al servidor de web a actuar segons els usuaris, així com a definir altres regles per als documents. Posem un exemple: imaginem que tenim un lloc web amb una secció públicament visible i una que només ho és per qui es registri: d'aquesta manera, cal saber qui pot visitar tot el lloc i qui, però, està subjecte a limitacions. Això es fa a través de l'arxiu .htacess, que en aquest cas defineix una llista d'usuaris i grups amb determinats permisos (en aquest cas es tracta de permisos de lectura) en certs arxius i directoris.A CADA usuari que sol·liciti l'entrada en un directori que estigui protegit, el browser us proporcionarà una imatge que li demanarà el nom d'usuari i la contrasenya per així comprovar la identitat, que passarà a Apache; si tot és vàlid, el servidor permetrà l'accés; si no, el negarà. 

 

 

18. El nom de l'usuari i la contrasenya de què es parlava abans, ¿se'ls amaguen al públic?


La resposta és sí, en els dos casos, per obvis motius de seguretat. Si fossin visibles per a tothom, serien de totes maneres difícilment descodificables; i si no estiguessin ocults, no es podria accedir-hi des de la web.


En aquest cas, dos nivells de seguretat suposen una bona aposta. De totes maneres, res no impedeix que es deixi la contrasenya a la vista de tots, però amb tots els riscos que això suposa. A més, no és aconsellable usar el fitxer /etc/passwd per a la llista dels binomis nom d'usuari-contrasenya.El perquè està clar: si algú accedís a ells, hauríeu de dir adéu a les seccions protegides del vostre lloc, així com al vostre sistema. De totes maneres, tornarem més endavant a l'argument de l'autenticació dels usuaris. 

 

 

19. ¿Apache pot suportar SSL?


Els Secure Socket Layer, normalment anomenats SSL, són un mètode per passar informacions reservades a altres màquines utilitzant diferents codis d'ocultació. Encara que en el paquet principal d'Apache no està present un suport SSL (sobretot per motius de "exportació" de codis d'ocultació, sobre els quals ens estendrem), que no podria convertir Apache en un programari lliure, ja que ja ho és, és possible trobar el que ens interessa a la pàgina "Related Projects", a la pàgina inicial del lloc d'Apache,http://www.apache.org/related_projects.html. 


 

 

20. Què vol dir donar-li a la pròpia màquina en la qual actua Apache 1 domain name?


Simplement, fer que Apache, un cop posat en marxa, s'adoni que ha de servir a través del protocol HTTP totes les peticions cap al nom de l'amfitrió de la vostra màquina. 
Sense un domain name, a més, Apache ni tan sols es posarà en marxa. 

 

 

21. Com es programa un domain name?


Obrint l'arxiu httpd.conf trobareu una directiva: ServerName a la que haurà de seguir el nom del domini triat per la vostra màquina. Només una advertència: eviteu utilitzar noms ja presents a la xarxa, per culpa dels quals Apache us mostri el vostre sistema principal en comptes del servidor remot sol·licitat a través del navegador; només a títol informatiu, el host "http://www.pippo.com" ja s'ha assignat. 

 

 

22. Però a mi no em serveix tenir un domain name; a la meva màquina només li dono un ús domèstic ...


Si es vol que Apache funcioni correctament cal que la màquina tingui un nom. A més, si us interessa provar scripts i similars, haureu de passar a la força pel servidor de web: i per tant forçosament cal assignar-li un nom a la màquina, ja sigui per al correcte funcionament del servidor de web, ja per provar o escriure els vostres scripts. 

 

 

23. Què són els mòduls?


Els mòduls són una part fonamental d'Apache: amb ells se li dóna al servidor la possibilitat d'interactuar amb els més variats tipus de documents, però no només. Per posar un simple exemple; suposem que es volen escriure uns script CGI per provar-los al servidor local: aquest ha de saber associar una extensió o més; en general, un tipus de fitxer a una acció. Després, ha de convocar el responsable de la gestió de l'arxiu i que aquest li doni l'output que cal mostrar al navegador de qui ho ha demanat. En el cas dels CGI, el servidor de web ha de reconèixer que l'script és un arxiu de text codificat d'una certa manera, ia més ha de saber a qui recórrer per a la seva interpretació i com fer-ho: aquí entra en joc el mòdul, en aquest cas mod_perl.so. I si el mòdul s'ha preguntat correctament, es tanca la cadena de preguntes, de manera que Apache pugui veure l'output de l'script. 

 

 

24. Com es carreguen els mòduls?


Un cop més, tot està a l'arxiu httpd.conf: preneu ara les següents línies: 

LoadModule perl_module /usr/lib/apache/1.3/mod_perl.so #LoadModule php3_module /usr/lib/apache/1.3/libphp3.so

 

La primera convoca el mòdul que Apache necessita per a la interpretació amb els script en Perl; la segona, per als script PHP. La diferència entre les dues escriptures és molt simple: hi ha un coixinet (#) davant de la segona; es diu que aquesta línia està comentada. En general, una línia comentada mai es llegeix, sinó que simplement s'interromp. Per tant, en aquest cas, quan Apache es posa en marxa, es carrega el mòdul mod_perl.so, però no libphp3.so: en el cas que volguéssim que també el mòdul relatiu al PHP es posés en marxa, n'hi hauria prou treure el coixinet de la segona línia (descomentarla) i donar-li a Apache un reinici. 

 

 

25. Quina és la diferència entre ServerRoor i DocumentRoot?


La diferència és enorme: en ServerRoot són presents els arxius de configuració d'Apache; però, en DocumentRoot és on s'inclouen els arxius "web visible", o sigui tots els fitxers que se li enviaran a al navegador que ho demani. En dues paraules, "el lloc", encara que aquesta no és la descripció més apropiada. 

 

 

26. Puc utilitzar el mateix directori com ServerRoot i com DocumentRoot?


Res ho impedeix, excepte potser el sentit comú. Els arxius en DocumentRoot es veuen des de l'exterior, mentre que els fitxers de configuració del servidor són reservats i, per tant, inaccessibles des de l'exterior. Per tant, hi ha la possibilitat d'usar el mateix directori, però sens dubte és molt desaconsellable fer-ho, encara que el vostre servidor no estigui concetado a la xarxa i el feu servir per a les proves. El consell és que tingueu els dos directoris separats, primer de tot per una qüestió d'ordre. A més, en els sistemes Unix, el directori / etc s'ha pensat per a tots els fitxers de configuració del sistema, per tant, crear un directori / etc / apache com ServerRoor (que en molts casos ja existirà) és una bona idea. 

 

 

27. Què són els host virtuals?


Els host virtuals (VirtualHost), per posar un exemple, són una mica com http://virtualhost.host.com.

 
Però Expliquem millor: si el vostre servidor és www.host.com, podreu crear el host virtual abans esmentat simplement ordenant-li a Apache que, en el cas que sigui convocat el VirtualHost i no el host directament, aneu a llegir els arxius en un altre directori que no sigui DocumentRoot, i conseqüentment els mani al navegador de qui ho hagi demanat.

 
Per tant, hi haurà un directori (DocumentRoot ) per als documents del host, i un (o més: es poden tenir més d'un VirtualHost) per a cada VirtualHost (a partir d'ara VH), que podreu definir al vostre gust.

 

 

28. Quins són els avantatges dels virtualhosts?


Quan el servidor respon tant a les peticions dirigides al host com a les dirigides als VH, el més interessant és la possibilitat de diferenciar físicament el host principal dels secundaris (precisament, els VH). Amb aquests, en efecte, podreu no només veure diferents documents segons es triï el host o el VH, sinó definir arxius de logs personalitzats pels VH, així com un administrador del servidor i similars. Per tant, haureu totes les dades dels VH separats pels del host principal; a més, òbviament, podreu definir arxius TOT de log per TOT VH, de manera que cada VH tingui els seus propis logs. 

 

 

29. Com es configura Apache per als VH?


Un exemple, encara que mínim, es troba al final de l'arxiu httpd.conf, entre els tags <VirtualHost> </VirtualHost>. A més, en el manual HTML que trobareu després d'haver instal·lat Apache, hi ha una secció dedicada exclusivament als VH.

 
Li dedicarem, de totes maneres, algunes pàgines a la configuració dels VH, a continuació en les pàgines del nostre lloc. 

 

 

30. Puc contribuir al projecte Apache?


Com ha quedat dit en algun lloc, el projecte Apache està format per voluntaris, el que significa que qualsevol pot unir-se a la causa, bé amb simples feedback o bé amb veritables idees i patch, o fins i tot amb bugfixes; els últims cal enviar-los a 
http://www.apache.org/bug_report.html per tal que els responsables els puguin avaluar. Les patches, però, es poden enviar directament a la llista de correu new-httpd@apache.org, indicant com a subjecte [PATCH], seguit per una breu descripció de les patch mateixes. Òbviament, contribuint al projecte, faríeu una cosa que agrairia tant l'equip de desenvolupament com, sobretot, els usuaris finals;i quan es parla d'un milió i mig de servidors web disseminats pel món, sense comptar les petites xarxes internes o els servidors "solitaris", no parlem, és clar, d'un grupet de persones.