Tragt man eine Internet-Domain in einem Debian-System ein für Apache2?



  • Also in /etc/hosts trägt man wohl die IP-Adresse ein und dann die Internet-Domain.



  • /etc/hosts wird nur fuer lokale Lookups verwendet, das hat nach auszen hin ueberhaupt keine Auswirkung.

    Typischerweise checkst du mal, was dir /sbin/ifconfig -a so an Interfaces ausspuckt; eines davon wird eine Public-IP haben, wo auch der Apache lauschen sollte.

    Deinem DNS-Server sagst du, auf welche IP deine Domain zeigen soll, da gibst du diese Server-IP an. Und dem Apache musst du dann noch mit einem VirtualHost-Eintrag sagen, welche Daten er fuer Requests an diese Domain ausliefern soll.



  • Also ich kenne aus eigener Erfahrung eigentlich nur die Variante mit Firewall und NAT. Da hat dann keines der Interfaces ne public IP. Und man trägt bei der Variante auch keinen DNS-Namen in der httpd.conf ein, sondern einfach die IP Adresse.



  • hustbaer schrieb:

    Also ich kenne aus eigener Erfahrung eigentlich nur die Variante mit Firewall und NAT. Da hat dann keines der Interfaces ne public IP. Und man trägt bei der Variante auch keinen DNS-Namen in der httpd.conf ein, sondern einfach die IP Adresse.

    Das hat nichts miteinander zu tun.

    Du beschreibst gerade IP-based VHosts, waehrend ich name-based VHosts erklaert habe. Das geht beides mit/ohne public IP. (Auch wenn natuerlich die Public-IP-Version bei IP-based VHosts fuer Shared Hosting etwas verschwenderisch ist, wird das trotzdem auch verwendet.)



  • @nman
    Nein, ich beziehe mich darauf:

    Typischerweise checkst du mal, was dir /sbin/ifconfig -a so an Interfaces ausspuckt; eines davon wird eine Public-IP haben, wo auch der Apache lauschen sollte.

    Und wenn der Web-Server hinter nem NAT steht, dann ist das eben nicht mehr so, weil dann kein Interface eine Public-IP hat. Mit VHosts hat das bis dahin noch überhaupt nichts zu tun.



  • Natuerlich, das ist schon klar.

    Aber das hier stimmt einfach nicht:

    Und man trägt bei der Variante auch keinen DNS-Namen in der httpd.conf ein, sondern einfach die IP Adresse.

    Bei der Variante mit Webserver hinter Firewall und NAT kann man genauso name based arbeiten wie IP based. Das eine hat mit dem anderen ueberhaupt nichts zu tun.

    Also: Klar kommt die Sache mit den VHosts erst nach der Sache mit der public IP, aber ob public IP oder nicht hat ueberhaupt keinen Einfluss darauf, ob man dann die IP oder die Domain eintraegt.



  • Ich hatte angenommen dass du meinst die Public IP bzw. den DNS Namen der auf die Public IP auflöst bei Listen einzutragen.
    Wobei ... wenn ich die Apache Doku richtig verstehe kann man bei Listen gar keine DNS Namen eintragen sondern nur direkt IPs.

    Wobei die einfachste Version einen Server hochzubekommen wohl sein dürfte nur den Port bzw. 0.0.0.0 bei Listen anzugeben.

    Die VirtualHosts kann man dann so oder so machen, das ist schon klar.



  • hustbaer schrieb:

    Ich hatte angenommen dass du meinst die Public IP bzw. den DNS Namen der auf die Public IP auflöst bei Listen einzutragen.

    Ach so. Nein, das meinte ich nicht. War nur als Erklärung gedacht, wie das ganze ablaufen soll und dass Apache auf diesem Level nur die IP interessiert und noch kein Domain-Name. An Listen ändere ich normalerweise ohne guten Anlass auch nix.

    Wobei ... wenn ich die Apache Doku richtig verstehe kann man bei Listen gar keine DNS Namen eintragen sondern nur direkt IPs.

    Ja, wäre anders sehr eigentümlich.



  • nman schrieb:

    Wobei ... wenn ich die Apache Doku richtig verstehe kann man bei Listen gar keine DNS Namen eintragen sondern nur direkt IPs.

    Ja, wäre anders sehr eigentümlich.

    Naja, ja und nein.
    Es werden an so vielen Stellen DNS-Namen verwendet, da hätte es mich auch nimmer gewundert wenn es bei Listen auch ginge.
    Irgendwo würde es ja auch Sinn machen, wenn ich - Public IP ohne NAT vorausgesetzt - einfach "Listen www.hustbaer.com:80" hinschreiben kann, und er nimmt dann die passende Adresse.
    So ein Name ist halt sprechender als ne doofe IP.

    Andrerseits wäre es auch unparktisch wenn der Server mal gestartet werden soll während der DNS grad rumspinnt. Also sehr unparktisch. SEHR. 🙂



  • hustbaer schrieb:

    Andrerseits wäre es auch unparktisch wenn der Server mal gestartet werden soll während der DNS grad rumspinnt. Also sehr unparktisch. SEHR. 🙂

    Eben. Man will einfach keinen Server komplett unnötig so stark von externen Services abhängig machen und nicht unnötig viele bewegliche Teile. Failover wird damit mühsamer, hinter Firewalls hat es nur mit Custom-DNS für interne Maschinen hin und tausend andere Sachen sind auch anstrengender.


Anmelden zum Antworten