Было бы очень интересно увидеть подобную статью — сам относительно недавно перевёл достаточно большой домен на Samba в Active Ditectory. Пришлось решать много интересных задач.
Вау! Очистка движущегося объекта, который перекрыл другой движущийся объект! Мои аплодисменты!
P.S. Главное чтобы не забыли сделать очистку попавших в кадр отражений лишних движущихся объектов.
Господа, у кого «всё работает» — обратите внимание — заблокированы 2 ip адреса (76.74.254.120 и 66.155.11.238) из 6.
Не работает только у тех, у кого клиент развернул DNS имя в один из двух заблокированных адресов!
Думаю «сползаний текста» не будет, если не переставлять мышь. Там сканированная картинка «склеивается» из массы небольших «фотографий» сделанных сенсором мыши — совмещение идёт по точкам. В ручных сканерах (по крайней мере старых) — совмещение сканированных строк осуществлялось по данным механического датчика (валика, который мог проскальзывать)
И кроме того, разве его пропустят (с subjaltname)? Я просто не знаю, не пытался еще.
Ну это зависит от центра сертификации. Если CA свой, то можно и заморочиться, только вот ИМХО нет смысла. Как часто на Ваши сервера приходят по FQDN с точкой в URL? Всем не угодишь.
Другое дело — если использование в URL FQDN открывает уязвимость, которую может эксплуатировать злоумышленник — это проблема и её надо решать.
Если собрались заморачиваться с SSL придётся добавить FQDN с точкой в Subject Alternate Name — иначе клиент не будет принимать сертификата при обращении к серверу по FQDN с точкой через HTTPS.
А тут я не соглашусь — ни разу не лучше. Даже при запуске ОС службы при такой конфигурации дольше стартуют. Не говоря уже о рекомендациях, ссылку на которые привёл CLaiN
Если нужны логические обоснования — посмотрите на зависимости служб dns и ntds и попробуйте смоделировать ситуацию при запуске (с AD интегрированным DNS конечно же.)
Думаю дело не только в браузерах.
Как минимум тут причастны ещё и web-сервера в плане интерпретации параметра host из URL.
Если стандартом предусмотрено, что в URL либо FQDN либо IP, значит
"http://example.com/"
должно быть равно для всех (стандарт ведь один для всех)
"http://example.com./"
Потому, что обе эти записи указывают на полное доменное имя домена example.com.
Впринципе на данную тему можно очень долго спорить, но главный итог этой статьи: мы имеем недостаточно формализованные стандарты, что влечёт за собой некоторые последствия.
Причём последствия не такие уж «страшные» для администратора, который о них знает и учитывает их при необходимости.
При поиске по слову «Jobs» в google и так вторая ссылка ведёт на вики статью про Стива Джобса, а третья на этот фильм на imdb. (Искал не авторизовавшись в google)
P.S. Первая ссылка — на украинский сайт по трудоустройству. ;)
не успевают создать необходимого информационного фона
Вот это формулировка!
Мне одному кажется, что хороший фильм всегда сам создаст себе «необходимый информационный фон»?
Максимум, что можно сделать для хорошего фильма — запустить анонсы. чтобы он не затерялся в море мусора, который нынче выпускается — дальше уже содержимое будет само работать на свою рекламу!
Ох уж этот маркетинг…
P.S. Главное чтобы не забыли сделать очистку попавших в кадр отражений лишних движущихся объектов.
Стоит, правда, чуть дороже.
Не работает только у тех, у кого клиент развернул DNS имя в один из двух заблокированных адресов!
Например: 66.155.9.238 — в реестре, а 66.155.11.238 — нет.
Ну это зависит от центра сертификации. Если CA свой, то можно и заморочиться, только вот ИМХО нет смысла. Как часто на Ваши сервера приходят по FQDN с точкой в URL? Всем не угодишь.
Другое дело — если использование в URL FQDN открывает уязвимость, которую может эксплуатировать злоумышленник — это проблема и её надо решать.
Если нужны логические обоснования — посмотрите на зависимости служб dns и ntds и попробуйте смоделировать ситуацию при запуске (с AD интегрированным DNS конечно же.)
Как минимум тут причастны ещё и web-сервера в плане интерпретации параметра host из URL.
Если стандартом предусмотрено, что в URL либо FQDN либо IP, значит должно быть равно для всех (стандарт ведь один для всех) Потому, что обе эти записи указывают на полное доменное имя домена example.com.
Впринципе на данную тему можно очень долго спорить, но главный итог этой статьи: мы имеем недостаточно формализованные стандарты, что влечёт за собой некоторые последствия.
Причём последствия не такие уж «страшные» для администратора, который о них знает и учитывает их при необходимости.
P.S. Первая ссылка — на украинский сайт по трудоустройству. ;)
Вот это формулировка!
Мне одному кажется, что хороший фильм всегда сам создаст себе «необходимый информационный фон»?
Максимум, что можно сделать для хорошего фильма — запустить анонсы. чтобы он не затерялся в море мусора, который нынче выпускается — дальше уже содержимое будет само работать на свою рекламу!
Ох уж этот маркетинг…
Быть может только стоит уточнить в заголовке, что речь идёт о миграции именно между датацентрами?