Wijzigingen | ||
---|---|---|
Herziening 1.1 | 2001-06-03 | |
Nieuwe beheerder, geconverteerd naar DocBook (SGML), gelicentieerd onder GFDL. | ||
Herziening 1.0 | 1995-11-24 | |
Initiële release. |
Dit document is beschikbaar onder de GNU Free Documentation License.
Een World Wide Web (WWW) Server is normaal gesproken een enkele machine bestemd voor het verwerken van HTTP verzoeken voor een enkele WWW-site. Eenvoudig gesteld, één WWW-site per machine. Aangezien de computerbronnen voor het verwerken van httpd verzoeken voor de meeste WWW-sites laag zijn, blijft de meerderheid van computerbronnen onbenut. Een virtuele WWW-site staat simpelweg meer dan één WWW-site waarbij een enkele processor wordt gedeeld. In plaats van www.domain1.com en www.domain2.com waarvoor twee fysieke computerapparaten nodig zijn, kunnen www.domain1.com en www.domain2.com op een enkel computerapparaat worden gelokaliseerd en kunnen zijn algemene bronnen delen.
Normaal gesproken hebben kleine computerfaciliteiten en ondernemingen geen bronnen om een toegewezen webserver en Internet verbinding te onderhouden. De kosten hiervan beginnen bij $10K per setup, en maandelijks $500-2500 voor het onderhoud. Kleine computerfaciliteiten en ondernemingen kunnen nu WWW ruimte "huren" van virtuele WWW providers. De klant kan de WWW "pagina's" dan onderhouden via een lokale telnet en/of FTP-verbinding.
WWW providers zoals InfoCom Networks http://www.infocom.net/ leveren WWW ruimte voor slechts $75 per maand. Dus de kosten om een WWW-site op te zetten zijn veelbetekenend lager dan voor het opzetten van een toegekende server en verbinding. De Virtuele Site heeft een belangrijk voordeel boven andere WWW adresseringsschema's zoals "www.jeprovider.com/~businessname". De Virtuele WWW server als zodanig heeft de mogelijkheid naar een nieuwe lokatie te verhuizen of een toegewezen WWW server op te zetten zonder de adressen te wijzigen. Het wijzigen van WWW URL's kan resulteren in een aanzienlijk verlies aan verkeer op je site, en voor veel ondernemingen publicatie updates.
Bij de meeste websites leveren www.domain1.com en www.domain2.com afzonderlijke IP's op. De virtuele host moet verzoeken voor beide sites af kunnen handelen om meerdere verzoeken van een enkele host te kunnen accepteren. De methode die wordt gebruikt om dit probleem op te lossen wordt IP-aliasing genoemd. Door het gebruik van IP-aliasing kan een enkele host verzoeken voor meerdere IP's accepteren. De virtuele Web Server moet de mogelijkheid hebben aliassen voor een IP te definiëren.
IP-aliasing is slechts een deel van de virtuele oplossing. Het Domain Name System (DNS) moet ook worden geconfigureerd dat het zowel www.domain1.com als www.domain2.com kan omzetten. Als domain1.com en domain2.com nieuwe domeinen zijn, dan moeten beiden bij het Internic worden geregistreerd. Thans brengt Internic $50 per jaar in rekening voor het onderhouden van je domein.
De meeste virtuele WWW-sites moeten ook in virtuele mail voorzien, of de mogelijkheid om alle mail door te sturen naar het virtuele domain naar een andere gebruiker of gebruikers.
Virtuele FTP of de mogelijkheid FTP te gebruiken met de standaard hostnaam "ftp.domain1.com" zou ook kunnen zijn geconfigureerd door de WWW provider.
Voor Linux versies 1.2.X zijn de IPalias patch alias-patch-1.2.1-v1 en alias-net-tools.tar nodig. Ik ben er niet zeker van of 1.3.X deze patch nog ondersteunt. Zie voor meer informaite over de IPalias ftp://ftp.mindspring.com/users/rsanders/ipalias/.
In plaats van de IPalias oplossing wordt het gebruik van meerdere dummy interfaces geopperd. Ondanks dat de dummy oplossing wellicht wel zal werken, schijnt het niet zo zuiver te zijn als de IPalias oplossing. Zie voor meer informatie over het gebruik van Apache met de dummy oplossing de virtuele hosting informatie van Aram Mirzadeh op http://www.qosina.com/apache/virtual.html.
Het enige dat moet gebeuren om een alias volgens de IPalias methode toe te voegen is: > /sbin/ifconfig eth0 alias www.domainX.com
De IPalias oplossing wordt bovendien op verscheidene andere platforms ondersteund.
Maak voor de virtuele klant een regulier Linux account aan met homedirectory en mail.
Virtuele Host implementaties veranderen nog steeds. Er bestaan een paar patches om een Virtuele host te ondersteunen. Bekijk de release notes van de server voor meer details. NCSA 1.5 en Apache hebben nu Virtuele patches opgenomen en ik heb me laten vertellen dat Spinner ook virtuele hosts ondersteunt.
Een virtuele patch ondersteunt de volgende srm.conf syntax, de tweede NCSA 1.5 methode echter voor het definiëren van een Virtuele host biedt meer flexibiliteit:
SubDocumentRoot www.domain1.com /usr/local/etc/httpd/docs/domain1 SubDocumentRoot www.domain2.com /usr/local/etc/httpd/docs/domain2 |
NCSA en Apache ondersteunen de volgende httpd.conf syntax:
ServerAdmin webmaster@domain1.com DocumentRoot /usr/local/etc/httpda/docs/domain1 ServerName www.domain1.com ErrorLog logs/errors.domain1.com TransferLog logs/access_log.domain1.com |
Zodra de IPalias patches zijn geïnstalleerd, voeg je het volgende toe aan het bestand /etc/rc.d/rc.local op je lokale webserver.
/sbin/ifconfig eth0 alias www.domain1.com /sbin/ifconfig eth0 alias www.domain2.com /sbin/ifconfig eth0 alias www.domainN.com |
Als je een nieuw domein opzet of het huidige domein wijzigt, dan moet je het domain registreren bij Internic. Het sjabloon is te vinden in ftp://rs.internic.net/templates/domain-template.txt
Named moet zo worden geconfigureerd dat je virtuele domain zichtbaar zal zijn voor de buitenwereld. Ik beweer geen expert te zijn als het gaat om DNS. Suggesties zijn altijd welkom.
directory /etc/named.data primary realdomain.com db.realdomain.com primary xxx.xxx.xxx.IN-ADDR.ARPA db.xxx.xxx.xxx primary 0.0.127.IN-ADDR.ARPA db.local primary domain1.com db.domain1.com primary domain2.com db.domain2.com cache . named.root |
Vervang x door je IP. |
$ORIGIN com. domain1 IN SOA domain1.com. hostmaster.domain1.com. ( 10134 43200 3600 604800 86400 ) IN NS ns1.realdomain.com. IN MX 10 mail.realdomain.com. IN MX 0 domain1.com. domain1.com. IN A xxx.xxx.xxx.xxx ;www.domain1.com IP $ORIGIN domain1.com. ftp IN CNAME domain1.com. www IN CNAME domain1.com. mail IN CNAME domain1.com. |
Je virtuele klanten zullen hoogstwaarschijnlijk de mogelijkheid willen dat mail gezonden naar hun domein wordt doorgestuurd naar een ander domein. Een paar wijzigingen in sendmail.cf zijn hiervoor nodig. Een paar maanden verschillende wijzigingen aan sendmail te hebben uitgeprobeerd, vond ik als eerste de volgende methode die werkt en waarvoor slechts één wijziging nodig is per virtuele site in sendmail.cf.
Haal de huidige versie van sendmail op met makemap btree ondersteuning.
Maak een bestand aan met de naam /etc/domainalias met de volgende indeling:
*@domain1.com localnet@realdomain.com *@domain2.com townplaz@realdomain.com *@domainN.com soracomp@realdomain.net webmaster@domain1.com somuser@anotherhost.com jamison@domain2.com anotheruser@somehost.com |
Maak een DB bestand aan
makemap btree /etc/domainalias.db < /etc/domainalias |
/etc/sendmail.cf wijzigingen:
Voeg voor elke nieuwe virtuele host een Cw record toe
Cwdomain1.com Cwdomain2.com |
Voeg de domainalias mapping slechts eenmaal toe.
Kdomainalias btree /etc/domainalias.db |
Toevoegen/wijzigen van Ruleset 98
################################################################### ### Ruleset 98 -- local part of ruleset zero (can be null) ### ################################################################### S98 R$+ < $+ . > $1 < $2 > remove trailing dots R$+ < $+ > $: < > $(domainalias $1$2 $) match user@address R< > $+ @ $* $: < $1 > $(domainalias * @ $2 $) match *@address R< $+ > * $* $: < > $1 $2 replace * with userid R < $+ > $+ $: < > $2 bugfix R< > $* $: $>3 $1 and rewrite using S3 |
Sendmail testen
Test de sendmailconfiguratie om de wijzigingen in sendmail.cf te verifiëren
sendmail -v -bv info@domain1.com |
De uiteindelijke bestemming zou moeten worden weergegeven.
Tot nu toe is het me niet gelukt om Virtuele FTP werkend te krijgen. Er bestaan een paar patches, en ik ben er zeker van dat er een werkende patch bestaat. We maken gewoon een werkdirectory /home/ftp/business/domain1 aan, maar een werkelijke Virtuele FTP zou fijn zijn.
Als iemand een oplossing zou willen aandragen, dan zou ik meer dan gelukkig zijn het hier toe te voegen.
Arnt Gulbrandsen heeft ftpd herschreven en er ondersteuning voor onafhankelijke FTP services in opgenomen. De Troll Tech FTP Daemon