Доступ к веб-сайту по VM
Я пытаюсь использовать VM, чтобы позволить мне и некоторым другим людям в компании к изменениям тест-драйва в хранилище Magento. VM находится вне моего контроля (главным образом) и размещается на поле Windows Server на нашей интранет. Я не знаю детали версии или фактическую используемую VM, но я могу, вероятно, получить эту информацию в случае необходимости. Я создал VM Ubuntu, установил Magento (v1.8). Я создал резервную копию из своего веб-магазина и восстановил к этому VM. Все это работает (достаточно хороший для того, что я делаю), если я остаюсь в VM.
Проблема состоит в том, что я не могу получить доступ к хранилищу, размещенному на VM снаружи VM.
Местоположение /var/www содержит апачский index.html по умолчанию. Хранилище расположено в .../var/www/magento
Если я просто указываю на браузер (снаружи VM) к IP-адресу VM, я получаю index.html апача по умолчанию. Если бы я изучаю апачский access.log, я вижу нормальные сообщения, которые Вы ожидали бы видеть.Отлично! Если я указываю на браузер на "/magento", я получаю веб-страницу значения по умолчанию IIS хостов VM! Апачский журнал доступа показывает, что возвратил некоторое перенаправление (301, 302) коды ошибок (я не очень знаком с этим).
О, и я действительно судил движущегося апача DocumentRoot кому: /var/www/magento и получил хост других проблем, таким образом, я отложил его.
Если это - проблема с хостом VM, можно ли дать мне подсказки, таким образом, я мог вовлечь надлежащих людей? Что я делаю неправильно?
apache2ctl -S вывод (замаскированные имена серверов):
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80 is a NameVirtualHost
default server example.com (/etc/apache2/sites-enabled/000-default:1)
port 80 namevhost example.com (/etc/apache2/sites-enabled/000-default:1)
Вывод cat /proc/version:
Linux version 3.2.0-77-generic (buildd@toyol) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #112-Ubuntu SMP Tue Feb 10 15:22:48 UTC 2015
Ну, я нашел часть ответа.
Это не проблема с сетью. Я использовал анализатор пакетов, чтобы узнать, что перенаправление, выданное apache, содержит адрес «localhost / magento», поэтому мой веб-браузер послушно запросил мою собственную машину Windows, которая вернула страницу с ошибкой IIS, а не IIS хоста виртуальной машины. Одна загадка раскрыта.
Следуя примеру @RVT, я использовал telnet и netcat и смог ПОЛУЧИТЬ отдельные файлы с сайта.
Затем я переустановил новую копию Magento и заметил, что это местоположение по умолчанию, которое Magento устанавливается в папку / var / www / magento. По другим причинам я помню, что установил оригинал в / var / www. Таким образом, было некоторое несоответствие между тем, что Magento хотел для корневой папки, и тем, что я установил. Переустановка (в ... / magento) работает отлично.
Настоящий ответ, вероятно, связан с изменениями в настройках Magento System-> General-> Web-> Unsecure Base URL и также, возможно, настройки Система-> Общие-> Интернет-> Параметр URL . Для полноты картины я обновлю этот ответ.
Поскольку я (пока) не могу комментировать, чтобы задать более ясные вопросы, мне придется опубликовать это в качестве ответа ...
Во-первых, убедитесь, что вы ВМ имеет мостовое соединение ... короче говоря, собственный IP-адрес в вашем сегменте локальной сети. Судя по вашему описанию, это звучит так, как будто он находится либо за общим, либо за прокси-соединением, и ваш сервер виртуальной машины может обслуживать свою собственную службу IIS.
Кроме того, было бы полезно просмотреть файлы журнала с сервера apache виртуальной машины ... сообщения 3xx важны (то есть в основном это означает, что виртуальная машина отправляет ваш трафик в другое место - может быть, она сама перенаправляет обратно на сервер виртуальной машины?).
Наконец, вы можете попробовать войти с как с виртуальной машины, так и с внешнего хоста ... вы можете telnet подключиться к порту 80 ... и выполнить команды, похожие на:
GET /magento HTTP/1.0
Hostname: yourhost.domain.com
\r\n
Обратите внимание, что вам следует перевести yourhost.domain.com в имя сервера и используйте двойной перевод строки / возврат каретки после строки имени хоста (т. Е. \ R \ n). Самая важная часть ответного сообщения должна следовать за этим запросом (то есть заголовки Apache). Это должно пролить свет на то, что на самом деле делает сервер.
Я делаю это постоянно для успешной работы на различных комбинациях ОС / VM / Server.
Кажется, ничего плохого в самом Apache нет, так что пока игнорируйте конфигурацию Apache. Вам нужно протестировать весь сетевой путь и подумать о том, как запрос будет перемещаться по сети от вашего рабочего компьютера до процесса Apache. Обычно запрос проходит:
Сотрудники -> Корпоративная Интранет -> Ваша ОС хоста -> Гостевая ОС ВМ -> Гостевая ОС ВМ -> Apache
Разделение сетевой топологии - это первый шаг в решении вашей проблемы, потому что вы должны найти, где запрос блокируется. Вот некоторые инструкции для этого:
Запустив корпоративную интрасеть, на которой сидит ваш Host-компьютер, убедитесь, что ваши коллеги могут физически получить доступ к вашему компьютеру по IP-адресу интрасети. Найдите свой ip-адрес с помощью
ipconfig /all(windows) илиifconfig(linux). С другого компьютера используйте ping tool, чтобы узнать, доступен ли ваш компьютер. Не переходите к шагу 2, пока не выясните, как связаться с вашим компьютером с помощью ping.Я так понимаю, вы можете связаться с http://[guest-ip-адрес], но можете ли вы получить доступ к своему веб-сайту VM по адресу http://127.0.0.1? Если вы не можете, смотрите Шаг 3 для настройки программного обеспечения ВМ, которое запускает ВМ. В противном случае, перейдите к шагу 4.
Программное обеспечение ВМ управляет виртуальным сетевым уровнем между ОС хоста и гостевой ОС. Скорее всего, она будет иметь NAT систему переадресации портов , которая может транслировать TCP-трафик между Host-портом 80 и гостевым портом 80. Однако, порт 80 часто защищен привилегиями супервизора на уровне хостовой операционной системы. Поэтому немного сложно сказать программе VM, чтобы она привязала порт 80, поэтому я рекомендую использовать вместо него порт 8080, так как он незащищен. Настройка переадресации NAT-порта между Host-портом 8080 и Гостевым портом 80. Убедитесь, что вы можете связаться со своим веб-сайтом @ http://127.0.0.1:8080. Возможно, у вас возникнет соблазн настроить Apache на использование порта 8080, но в этом нет необходимости. Программное обеспечение VM под управлением вашей гостевой операционной системы может перевести Host-порт 8080 в гостевой порт 80. Играйте с настройкой сети VM до тех пор, пока не получите http://127.0.0.1:8080.
Убедитесь, что вы можете ударить по вашему веб-серверу с вашей операционной системы хоста @ http://[your-host-ip]:8080. Если нет, проверьте, работает ли у вас брандмауэр на вашей операционной системе. Начните с его временного отключения и повторите проверку. Если вы все еще не можете зайти на сайт, вернитесь к Шагу 3. Если это возможно, снова включите брандмауэр, но убедитесь в том, что ваше программное обеспечение VM исключено, или откройте порт 8080.
Убедитесь в том, что вы можете поразить ваш веб-сервер с вашего сайта с другого компьютера в вашей сети копоративной передачи данных @ http://[your-host-ip]:8080. Если Вы не можете, между Вами и Вашими коллегами может быть корпоративный брандмауэр. Облом. Это также может быть брандмауэр вашей операционной системы, повторите Шаг 4.
К концу этого, ваши коллеги должны быть в состоянии добраться до сайта, работающего на вашей ВМ.
.