Последние сообщения

Так движок то DST Platform то один, странно почему нельзя. 

Николай Одинцов

Движок один у всех решений, а вот базы разные, по этому там только ручками если только, но писать придется много. Я знаю это потому что года 3 назад запустили свой маркетплейс на DST Marketplace а потом захотели перейти на DST Multivendor, проблема была в том что наш маркетплейс уже был наполнен 300К товарами и множеством информационных страниц, поставщиками и.т.д. то есть просто перейти сразу с одного на другой уже был не вариант, заказали доработку и разрабы переход делали 1,5 месяца, так что там не быстро это   

Так движок то DST Platform то один, странно почему нельзя. 

Да я то Игорь не спорю, просто подметил. Интересно другое, можно ли с DST Store перейти на коробку Мультивендора? 

Николай Одинцов

Нет, там базы уже разные, Маркетплейс и Мультивендор это две совершенно разные системы, по этому точно нельзя

Да я то Игорь не спорю, просто подметил. Интересно другое, можно ли с DST Store перейти на коробку Мультивендора? 

Хорошее обновление, сразу видно что DST Store создан на базе DST Marketplace, после того как обновляется решения маркетплейса, за ним сразу примерно через пол месяца идет обновление магазина

Николай Одинцов

Так конечно что база одна, тот же DST Store по этому и позволяет из магазина сделать маркетплейс, если бы базы были разными это было бы не возможно. 

Хорошее обновление, сразу видно что DST Store создан на базе DST Marketplace, после того как обновляется решения маркетплейса, за ним сразу примерно через пол месяца идет обновление магазина

Не знаю, у того же Битрикса Git открыт и все видят что и как там происходит

Олег Котов

Так его по этому и ломают, тут в этом все и дело что система с открытым исходным кодом но в закрытом доступе, что радикально важно для клиентов которым нужна реальная безопасность. 

Не знаю, у того же Битрикса Git открыт и все видят что и как там происходит

А мне кажется стоит вести лог по исправлениям, чтоб сразу понимать где и чего было исправлено, или тот же Git, что еще удобнее, чтоб сразу понимать что обновляли и что конкретно делали. 

Олег Котов

Ну это конечно правильно Олег, вот только GIT DST не публичный, делая его публичным систему подвергнут тому что код будет открыт а значить возможностей для взлома будет больше, так что лучше скорее всего вести логи по исправлениям, но я сам разработчик и знаю что это такое, это безумно начнет тормозить скорость выхода новых компонентов и модулей т.к. ведение лога подразумевает кропотливую работу что приведет на 50-60% каждый функционал будет выходить дольше, так что нет, тут нет однозначных решений. 

А мне кажется стоит вести лог по исправлениям, чтоб сразу понимать где и чего было исправлено, или тот же Git, что еще удобнее, чтоб сразу понимать что обновляли и что конкретно делали. 

Думаю это совершенно верный подход, я например не хочу чтоб мои наработки которые я делал в течении полу года слетали по причине новых обновлений, по мне так лучше ручками их все внести хотя и затратить на это время конечно придётся. 

Настройка домена сайта, на который вы заходите, определяет, сколько будет считаться актуальной УЖЕ сохраненная у вас локально эта запись. Можно обнулить кеш записей принудительно, можете из кеша даже эту конкретную запись удалить через оснастку сервера.

Вчера донастраивал DNS сервер.

1. Открываем DNS осначтку.
2. Правой клавишей по DNS.
3. Свойства.
4. Сервер пересылки.
Должен быть твой DC и выше них твой маршрутизатор
Вбиваешь ip. Имя сам подберет.
Router 192.168.1.1
DC 192.168.1.10
Теперь твой DC сервер знает как все пк в твоей сети вывести в интернет.
Через DNS роутера.

Зона прямого доступа.
Там ищи Статический DNS запись. Которая указывает на старый сайт.
А также в DNS записях роутера

Нужно определить, что у вас слушает на порту 8888 (например ss -tnlp) и добавить сертификат в настройки этого самого, что слушает.

Внутренний DNS, если встречает запрос ответа на который он не знает, может:

1 — ответить что не знает такого имени/адреса
2 — переслать запрос дальше согласно настройкам пересылки (forward)

Работает это исходя из зоны. Если он ответственный за зону mysubdomain.mycompany.ru, то запрос comp1.mysubdomain.mycompany.ru обработает только он. Если нет такого имени, ответит что нет.
Запрос же comp1.mycompany.ru или ya.com он перешлет указанному у него серверу пересылки, поскольку они не входят в его зону ответственности.

Можно так же создать зону othersubdomain.othercompany.ru и сказать что для нее ответственный сервер 192.168.10.3 и все запросы в эту зону и подзоны будут отправляться на указанный сервер, в то же время запросы ya.com пойдут на общий сервер пересылки.

В процессе работы ДНС сервер как и положено кеширует результаты запросов, согласно указанным TTL. Кеши при необходимости можно сбросить (через оснастку управления DNS сервером). Тогда при следующем запросе он обратиться за помощью к серверу пересылки. Но и там может лежать устаревшая запись и вот там вы руками уже не обновите кеши, придется ждать пока они сами протухнут. Для понимания какой сервер какой ответ вам дает можно использовать nslookup.

Например:
nslookup
comp1.mydomain.mycompany.ru
(ответ в котором дефолтный днс скажет все что думает)
server 77.88.8.8
comp1.mydomain.mycompany.ru
(теперь яндекс скажет все что он знает)