Абсолютное не верное решение и абсолютно другое чем в первом посте. Я объяснил почему выше…
Я имею смелость полагать, что база данных одна, и ответ HNBS означает именно это. Но можно просто перепроверить спустя недельку.
DNS возвращается потиху в норму, скоро dvlottery.state.gov сайт будет доступен, но возможно будет медленее работать в первое время
как проверил что база или код во время отключения не была девелопмент?
Хотелось бы получить более развернутый комментарий.
Единственная разница моего метода проявится в случае специфических настроек веб-сервера, который обслуживает данный сайт. И эта разница закончится какой-то ошибкой на экране, скорее всего.
Одну из причин я выше указал, и могу набросать с пару десятков других причин, но не вижу в этом смысла тратить моё время. Ваше решение с айпишником будет верным если вы подтвердите что ДНС имя не hard coded в программном коде, что front end virtual host настроен одинаково как для айпи адреса так и для dvlottery.state.gov. Пока вы это не подвердите ваш решение не будет являтся верным.
Тогда есть милип***рический шанс, что результат HNBS может измениться на другой.:clapping:=0
При всем уважении, я тоже трачу своё время на попытку разобраться, что же такого ужасного, заменить решение с адресом в строке на подмену того же адреса в локальном резольвере.
Даже если что-то там где-то захардкожено на бэкенде, бэкенд использует с вероятностью 99.99% правильный (потому что authoritative) DNS, так что единственной проблемой становится добраться до фронта. Крайне маловероятно, чтобы инфраструктура этого севера была бы настолько сложна, что фронт и бек использовали бы резольверы с разным содержанием кеша.
Собственно, моя претензия заключается в том, что ваше решение в первом посте и моё решение в комментарии выше - одно и то же решение, за исключением заголовка к обслуживающему веб-серверу. А не “совсем другое и в корне неверное”.
(добавлено) Кстати, говорить, что “DNS-name захардкожен” - это в известной мере оксюморон, потому что “захардкожен” всегда относится к указанию адреса напрямую вместо FQDN.
ок, потратил немного своего времени чтобы показать почему.
- Добавь в хостс файл следующее и кэш в браузере почистите перед тестом:
45.56.76.23 dvlottery.state.gov
2.Открываем теперь в бразуере:
http://dvlottery.state.gov/
- Открываем в браузере:
http://45.56.76.23/
Разницу видите? Два абсолютно разных документа открываются на одном и том же сервере с одним и тем же айпишником
Даже если что-то там где-то захардкожено на бэкенде, бэкенд использует с вероятностью 99.99% правильный (потому что authoritative) DNS, так что единственной проблемой становится добраться до фронта. Крайне маловероятно, чтобы инфраструктура этого севера была бы настолько сложна, что фронт и бек использовали бы резольверы с разным содержанием кеша.
опять же всё зависит как настроен фронт и как настроен бэкэнд, также не зная инфрастрструктуру маловероятно что ваш предположение верно
Исходя из того что ДНС убрали, я уверен что конфигурацию не меняли вообще, поэтому указывая правильное ДНС имя позволяет нам открыть рабочий веб сайт.
Собственно, моя претензия заключается в том, что ваше решение в первом посте и моё решение в комментарии выше - одно и то же решение, за исключением заголовка к обслуживающему веб-серверу. А не “совсем другое и в корне неверное”.
Собственно ваше решение я уже похерил примером выше
(добавлено) Кстати, говорить, что “DNS-name захардкожен” - это в известной мере оксюморон, потому что “захардкожен” всегда относится к указанию адреса напрямую вместо FQDN.
мне это тяжело коментировать так как вы здесь в одной фразе противоречите себе
я на день оставлю сервер, если не успеете посмотреть тут скриншоты