Изпечатай

[PAIN1]

Искам някой да ми изясни схемата по която става.
В смисъл, примерно на едно локално ип 10.3.0.40 от малка вътрешна мрежа,
да отговаря примерно на site1.10.3.0.40 и site2.10.3.0.40 в различни DocumentRoot съответно.
В httpd.conf постъпва тама

Примерен код

NameVirtualHost *:80 <VirtualHost *:80>    ServerName http://www.homepage.10.3.0.40    DocumentRoot /mnt/ext3/tmp/pub/code/project    ErrorLog /mnt/ext3/tmp/pub/code/project/Error.log    CustomLog /mnt/ext3/tmp/pub/code/project/access.log custom </VirtualHost> <VirtualHost *:80>    ServerName http://www.code.10.3.0.40    DocumentRoot /mnt/ext3/tmp/pub/code/    ErrorLog /mnt/ext3/tmp/pub/code/Error.log    CustomLog /mnt/ext3/tmp/pub/code/access.log custom </VirtualHost>

Ако това което съм написал горе е вярно, остава частта със DNS, която не ми е ясна като идея. Точно какво трябва да стане. Ако това горе пък го бъркам някъде, съответно, кажете ?
Съмнява ме, че не мога да направя това с 10.3.0.40 и трябва някак да го направя да отговаря на name някакъв ?

[Bogo]

Ами за name based virtual host мисля че имената трябва да завършват на .com .net .org и тн.

не е така както си го написал.

значи искаш на IP 10.3.0.40 да отговарят две съвършенно различни страници нали?
например:
http://www.site1.com
i
http://www.site2.com

1-во преди да ти заработи virtualhost-а на apache тези два адреса трябва да се резолват от DNS сървера. това трябва да си го направиш и е друга тема. Ако си го направил правилно като напишеш

host http://www.site1.com
трябва да получиш
http://www.site1.com has address 10.3.0.40
и
host http://www.site2.com -> 10.3.0.40

И двата адреса трябва да връщат IP-то!!!



2-ро описваш си virtualhost-ове в апашито

<VirtualHost 10.3.0.40>
    ServerName http://www.site1.com
    DocumentRoot /mnt/ext3/tmp/pub/DIR1
</VirtualHost>

<VirtualHost 10.3.0.40>
    ServerName http://www.site2.com
    DocumentRoot /mnt/ext3/tmp/pub/DIR2
</VirtualHost>



а схемата по която работи е следната. ако някой напише http://www.site1.com DNS сървера връща 10.3.0.40. След това браузера прави HTTP заявка на 80-ти порт на 10.3.0.40 казва дай ми страница
http://www.site1.com. Koe да се изисква е част от HTTP протокола.. по това   че се съобщава и адреса в http (http://www.site1.com)  и апашито познава кой виртуален хост да върне.


това с виртуалните хостове например няма да работи ако някой въведе в полето на адреса на браузера ИП - 10.3.0.40. какво ли трябва да се добави за да връща единия от адрестите по подразбиране?

[PAIN1]

А не трябва ли като домейн след страницата да седи и хоста на машината където е сайта, примерно не както си написал .com ами машината където е сайта ?

[alabal]

Не - не трябва - това се описва в bind или при хостинга ти.
Пускането на bind на мрежа от типа 10.0.0.0, обаче е забавно и достойно усилие.

Интересно ми е обаче, как може така да се настрои BIND-а че да резолва някои несъществуващи домейни.

Например работи си нормално резолва правилно целия съществуващ И-т обаче искаме да върне направо 'site1.com' или 'alabala' на  10.3.0.40,
независимо дали 'site1.com' или 'alabala' са регистрирани или несъществуващи домейни.


Това би работило правилно и не би имало никакво противоречие с орагнизацията на DNS-сите, при условие че на клиенския комютер е настроен да се използва точно този попроменен DNS.

как трябва да се опише това. някой да има пример?

[alabal]

http://us5.samba.org/samba....CP.html

Нещо подобно ли търсиш за частна мрежа?

[PAIN1]

Не точно. На мене нищо не ми трябва, правя го за спорта. Но се насочих горе долу
 какво трябва да прочета и ще веднага щом се освободя .....

[Hapkoc]

naka, аз се сещам за два варианта с ISC BIND. Ако се не лъжа, това за което питаш се нарича Split DNS.

edit: Всъщност split DNS се нарича по скоро конфигурация при която се дават различни отговори за една и съща зона в зависимост от адреса на машината, от която идва заявката, но така и така съм написал по-надолу нещата, току виж са полезни на някой. Иначе това, което питаш може да се направи като просто се пусне named да слуша и да отговаря на заявки само за локалната мрежа. В такава конфигурация можеш да дефинираш каквито си поискаш домейни, но те ще важат пак само в рамките на локалната мрежа.

1. Можеш да пуснеш две инстанции на named, с две напълно различни конфигурации, като да кажем едната слуша на IP адреса към вътрешната мрежа и отговаря на заявки само от тази мрежа. Няма проблем на така пуснат named да конфигурираш нерегистриран в глобалната система домейн, например nonexistent.domain, доколкото отговори за този домейн ще се дават само в рамките на локалната мрежа.
 
2. Изисква BIND 9 - там могат да се конфигурират views или изгледи. При такава конфигурация можеш да постигнеш същия ефект с една инстанция на named, която дава различни отговори в зависимост от адреса на машината, от която идва заявката.

Описанието е нещо от рода на:

--------- named.conf ------------
...
view "local" IN {
  match-clients { 192.168.0.0/24; };
  match-destinations { 192.168.0.1; };

  zone "nonexistent.domain" {
    type master;
    file "path/to/zone/file";
    ...
  };
};

view "public" IN {
  match-clients { any; };
  match-destinations { <public-ip>; };

  zone "public.domain.com" {
    type master;
    file "path/to/zone/file";
    ...
  }
};
---------------------

match-clients описва заявките от кои адреси да се обработват от съответния изглед. match-destinations описва заявките към кой адрес (от тези на които слуша named) да се обработват от този изглед. При съвпадение на двата параметъра, заявка от 192.168.0.13 към 192.168.0.1 за домейн nonexistent.domain ще върне съответния адрес описан във файла на този домейн от local изгледа.

При заявка от адрес извън 192.168.0.0/24 мрежата или заявка към <public-ip> заявката ще се обработи спрямо public изгледа и заявка за nonexistent.domain би следвало да върне NXDOMAIN.

Надявам се да съм разбрал правилно въпроса и да съм ти отговорил.

Браво Hapkoc, това си го записвам и принтирам.

какво обаче би станало ако просто се опише един домейн some-domain.com (независимо дали е регистриран или несъществуващ) в една зона и всички потребители са си настроили да ползват точно този DNS.

Не би ли трябвало BIND-a да върне/резолва първо този домейн, тъй като той си го знае. а да не се опитва да го търси по целия път -(. com. some-domain.com.)

Разбира се се това с  view-тата е много гъвкаво и така както си мисля по-горе, всички клиенти биха имали еднакво знание за  some-domain.com

[hary]

naka, точно така става '>
Дори много често съм срещал доставчик на интернет услуги, чиито ДНС сървъри са отговаряли в миналото за даден домейн , да продължава да лъже потребителите си ( т.е. продължава да отговаря на запитвания за тая зона), въпреки че домейна отдавна е продаден и за него отговарят други ДНС сървъри.
Сървъра има съответната зона и я сервира без да пита руут ДНС-ите.

Към основното запитване имам да добавя една полезна команда :
httpd -S
Показва конфигурацията на виртуалните хостове, като явно се виждат namebased VHosts , а също и кой ще се покаже по подразбиране ( ако се зареди директно http://<IP>/ )
Много удобно за проверка '>