Light-electric.com

IT Журнал
7 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Смена основного домена g suite скрипт

Угроза блокировки для пользователей бесплатных аккаунтов Legacy G Suite (ex. Google Apps)

Стало известно о массовых случаях отключения бесплатных Legacy G Suite (ex.Google Apps) аккаунтов по всему миру начиная с декабря 2017 года. Чем это грозит и что делать?

Много других пользователей присоединяются в комментариях в этих ветках саппорта. Кого-то заблокировали без предупреждения, а кому-то дали 15 дней на сохранение данных. Администраторам пришли письма вот такого содержания:

It appears your G Suite account was acquired from an unauthorized reseller who provided these services in violation of Google’s Terms of Service. This means that we must close your existing account, and you will be required to register a new one to continue using G Suite.

To avoid future issues, you need to know:

We’re closing your existing G Suite account on 2017-12-14.

You can still save your data so that it will be available to you after your account is closed. You must migrate your data no later than 2017-12-10 or it will be deleted.

To continue using our services, you can register a new G Suite account and your first 14 days will be free, along with support for the duration of the subscription. If you have saved data from your old G Suite account prior to the deadline above, you will be able to migrate that data into your new account.

We apologize for any inconvenience.

The G Suite Team

Поскольку у Legacy-аккаунтов нет приоритетной поддержки, то всех отправляют на форум, где дается крайне скудное объяснение: вы приобрели свой аккаунт у неавторизованного реселлера, и поэтому ваш домен нарушает правила пользования и будет отключен.

Немного истории

В далеком 2006 году Google выпустила Google Apps for Your Domain и предлагала использовать их сервис-компаниям любого размера бесплатно. Немногим позже, в феврале 2007 г. Google анонсировала версию Google Apps Premier Edition с приоритетной поддержкой за 50 долларов (между прочим, за 11 лет цена не изменилась! в долларах, конечно, но все равно не многие вендоры могут похвастаться таким постоянством). В том же 2007 году компания Softline подписала партнерский договор c Google.

Позже Google ограничила число бесплатных учеток до 100, далее до 50, до 10, а в декабре 2012 г. и вовсе отменила бесплатные учетные записи для новых доменов. Но ранее подключенные аккаунты продолжали работать.

Так появился черный рынок б/у доменов с подключенным Google Apps. Ссылок приводить не буду. Схема проста – покупатель получает ранее созданный домен с передачей прав у регистратора, и в консоли администратора Google меняет основной домен на свой основной. Либо, если был куплен домен второго уровня, добавляет свой нужный домен как Alias к бесплатной legacy подписке.

Вернемся же к проблеме отключения!

Возможные причины отключения (кто в зоне риска)

Пока нет четкого понимания, как Google выловил нарушителей, но вот несколько вариантов, кто в зоне риска:

  • Была смена основного домена на Legacy Google Apps (G Suite).
  • У одного домена есть десятки доменов третьего уровня с подключенными Legacy подписками, особенно если каждая имеет алиасы.
  • Какой-то поставщик подарил вам бесплатную подписку на Legacy G Suite вместе со своим сервисом (см. вариант №1).
  • Домен подключен к G Suite for Education, но домен не относится к образовательному учреждению.
  • Также Google предоставлял доступ к G Suite для разработчиков (не для повседневного использования).

Основной документ, регламентирующий действия пользователей, – Acceptable Use Policy – можно изучить тут.

Что делать, если меня отключили?

Если вас уже отключили без предупреждения, а данные нужно спасать – ваша задача любой ценой обратиться в Premier support и попросить их включить вашу подписку на несколько дней. Можно попробовать обратиться либо через другой домен с платной подпиской, либо через реселлера, например, Softline – мы будем рады помочь. Пишите нам на google@softline.ru.

Инструкция по переносу данных и сохранению основного домена

Согласно инструкции от Google, вы должны сделать бэкап ваших данных вне G Suite до того, как отключат, затем удалить свою подписку. Далее необходимо купить платную подписку на этот же домен и сделать миграцию данных обратно в G Suite.

Однако, как выяснилось, есть возможность обойтись более простой процедурой – мы подключили Legacy клиента к G Suite через консоль Softline и запросили поддержку не отключать домен, запрос прошел некий этап согласования, и клиенту разрешили не удалять подписку. При этом поддержка оговаривает, что каждый случай уникальный и проходит отдельное согласование.

Если не согласовали простой вариант – остается только мигрировать данные. Вот подробная инструкция:

  • Регистрируем новую подписку на G Suite, например, new.domain.ru (можно через нас).
  • Создаем таких же пользователей на новом домене.
  • Запускаем перенос данных почты средствами миграции данных от Google.
  • Переносим файлы пользователей:
    — через предоставление доступа и скрипт Drive Migrator (позволяет создавать копии файлов и вложенных папок со стороны пользователя). Права доступа к файлам нужно будет вручную прописывать заново;
    — или с помощью платного сервиса Cloud Migrator – полный перенос данных с правами доступа ко всем файлам.
  • Удаляем старую подписку в консоли – делаем по инструкции.
  • В течение 24 часов старый домен станет доступен, и в новой консоли new.domain.ru нужно сменить основной домен на старое имя domain.ru.

Есть еще один способ без удаления аккаунта и переноса данных.

Если не хочется испытывать судьбу!

Если отключение G Suite сулит потерями для бизнеса – рекомендуем переходить на платную версию: ни один из наших клиентов, ранее бывших на legacy, такое письмо не получал. К платным аккаунтам, обслуживаемым через авторизованного Premier реселлера, претензий быть не может.

Здесь можно прочитать про различия между платными версиями G Suite.

Как влияет на GCP изменение основного доменного имени G Suite и переименование пользователей?

Я ищу, чтобы изменить основной домен мой экземпляр номер. У нас есть настройка организации GCP и ряд проектов, созданных и принадлежащих пользователям.

Цель состоит в том, чтобы изменить основной домен экземпляра G Suite, а затем переименовать пользователей в новый домен.

Я пытаюсь тренироваться, если это будет бесшовным или это повлияет:

Узел организации GCP участие в проектах и т. д.

1 Ответ

думаю, это едва ли повлияет на GCP, потому что GSuite — это что-то другое.

смотрите учебник -email владельца проекта будет изменен на IAM .

Перед переименованием учетной записи суперадминистратора, с которой вы вошли, обязательно запишите новое имя в безопасном месте. Вы автоматически выйдете из системы после переименования, и вам понадобится новое имя суперадминистратора, чтобы войти обратно.

побочный эффект должен быть вызван только при наличии жесткого кода адреса email владельцев проекта.

это все равно должно быть то же самое ID для организации, независимо от того, как она называется.

Похожие вопросы:

Я использую Python flask. У меня есть запрос POST с некоторой полезной нагрузкой, например: abc.com/hello/hello1 Я хочу перенаправить это (302) на: xyz.com/hello/hello1 только изменение доменного.

Я хотел бы иметь возможность синхронизировать электронную почту и календари всех пользователей g-suite. Есть ли возможность использовать присягу администратора организации и использовать api только.

Я хочу отправлять электронные письма с адреса группы G Suite Google, например group@mydomain.com . Учетная запись, которую я буду использовать для отправки электронных писем, находится в другом.

Читать еще:  Настройка контроллера домена с нуля

Если параметр Cloud Service отключен в домене G Suite, это отключает возможность для всех пользователей домена G Suite создавать проекты на платформе Google Cloud. Если вы находитесь в этой ситуации.

В настоящее время у меня есть активный каталог, связанные с набором подписок, для компании я работаю на платформе Azure. Однако ‘Default Directory’ AD находится в домене forenamesurnamehotmailco .

Я заглянул в G Suite admin APIs и нашел эту функцию: GET https://www.googleapis.com/admin/directory/v1/users Я получаю список всех пользователей, но ни у одного пользователя в списке нет номера.

Интернет-магазин chrome поддерживает 3 различных типа приложений: расширения, размещенные приложения и упакованные приложения. Расширения предназначены для приложений, которые имеют минимальный UI и.

Это мой простой скрипт приложения, который я использую в Google forms: function onFormSubmit(event) < var x = MailApp.getRemainingDailyQuota(); >Я только что подписался на бесплатную пробную версию.

У нас, как у небольшой компании, есть учетная запись G Suite Edu. Наши электронные письма обрабатываются где-то еще, но мы хотели бы, чтобы email каждого пользователя в домене переадресовывались на.

У меня есть учетная запись G Suite. GCP создал организацию автоматически, когда я вошел в систему с помощью G Suite super admin. Когда я пытаюсь создать проект в консоли, организация выбирается.

Подключение и настройка почты от G Suite — МХ записи, подтверждение домена и др.

Есть у меня один клиент, который использует G Suite для своего бизнеса — это сборка разных инструментов и приложений Гугла: корпоративная почта Gmail, совместная работа, хранение и поиск данных в облаке и др. Одна из фишек там — возможность реализовать обработку всей почты через Google серверы вместо регистратора. Этим мне и пришлось заняться. Задача не сложная, но вдруг кому-то пригодится этот небольшой мануал. В статье описывается опыт работы под WordPress CMS, но, сам принцип подходит и любым другим сайтам.

В общем сложности весь процесс реально разделить на 3 этапа, последний из которых не является обязательным:

  1. Подтверждение прав на домен.
  2. Задание правильных записей MX для G Suite.
  3. Настройка корректной отправки писем с сайта через SMTP-протокол.

В моем примере был проект на Вордпресс, поэтому третий пункт там был рекомендуемым (с почтой в системе иногда случаются глюки).

Подтверждение прав на домен в G Suite

Скорее всего вы покупали свои домены по доступным ценам в компаниях партнерах регистраторов, а не через Google (что, конечно, намного более выгодно). В этом случае вам придется подтверждать право собственности именно через них либо там, где вам предоставили опцию редактирования DNS записи (иногда это делается в отдельном сервисе). Все детали можно узнать в тех.поддержке вашего регистратора.

1. Итак, первым делом переходите в свой аккаунт G Suite, где в консоли админа будет пункт «Подтвердить домен» или «Начать установку».

2. Для сторонних компаний-регистраторов нужно найти пункт «Выбрать другой способ», где будет вариант «Добавить запись TXT или CNAME».

3. Установите галочки «Вход выполнен» и «Панель управления доменом открыта», после чего увидите параметры для подтверждения доменного имени.

4. Далее переходите к управлению DNS/NS своего регистратора. В этом инструменте нужно будет добавить новую ТХТ запись (например, в nic.ua это выглядит так):

  • в первом поле (имя, host, alias и др) пишете @ или оставляете пустым;
  • в параметре TTL (время жизни) оставляете значение по умолчанию или 86400;
  • в качестве типа записи ставим TXT (или CNAME);
  • ну, и в последнее поле добавляете свой проверочный код.

Далее сохраняете все настройки. Если появится какое-то предупреждение, можете не переживать — TXT-запись на работе вашего веб-проекта никак не отразится.

5. Возвращаетесь в панель G Suite, где отмечаете галочку, что TXT параметр уже установлен и завершаете процедуру подтверждения.

Обновление DNS займет от нескольких до 72-х часов, но обычно новые значения активируются значительно раньше. Страницы Гугла и регистратора пока что оставляете открытыми и переходите к следующему шагу.

Задание MX записей для G Suite

Тут все очень похоже на предыдущий пункт. Если вы с ним разобрались, то будет уже гораздо проще. Опять переходим к настройке DNS домена, где надо, во-первых, удалить все существующие MX-записи, а во-вторых прописать вместо них следующие:

В некоторых случаях в названии сервиса нужна точка (как указано в примере), иногда значения полей отличаются. Детальная инструкция по этому пункту находится тут. Там же встречается инфа о методе подтверждения домена через еще одно поле MX, но мне кажется проще/логичнее это делать с помощью TXT-поля. Вот как все выглядит для хостинга от Mirohost.

После сохранения всех изменений должно пройти от нескольких часов до 48-72х. Ваш новый адрес может подключиться и быстрее, но для поступления первых писем нужно чуть больше времени (поэтому не спешите тестировать).

Отправка почты через SMTP в WordPress

Не знаю по каким именно причинам, но иногда в Вордпресс лагает встроенный механизм отправки почты, поэтому многие советуют ставить сторонний плагин. Один из самых популярных решений — WP Mail SMTP by WPForms. Тут вам и нормальная оценка, и более 1млн. скачиваний. Данное решение позволяет использовать сторонний SMTP-провайдер: Mailgun, SendGrid и Gmail.

После установки и активации переходите в настройки модуля, где в первой вкладке есть парочка важных параметров:

  • У меня выбран вариант smtp.gmail.com, который, наверное, можно было включить, активировав одноименную опцию.
  • Для порта использую значение = 465.
  • А чуть ниже вводите свой логин/пароль для созданного почтового ящика в G Suite.
  • Плюс дополнительно можно включить шифрование, указать имя и Email-адрес, отображаемое получателям писем.

Еще одно полезная фишка в WP Mail SMTP by WPForms находится во второй вкладке — вы можете быстро отправить тестовое сообщение на любой свой Email дабы проверить корректность работы всех настроек.

Итого. В принципе, мне кажется, я все достаточно понятно изложил. В статье есть ссылки на соответствующие разделы Справки Гугла — там еще более детально рассмотрены эти моменты. Также не бойтесь обращаться в тех.поддержку своего регистратора доменного имени — в хороших конторах вам обязательно подскажут что и как правильно сделать. Лично я делал подтверждение через TXT, но если честно, не помню нужно ли после этого ждать пока G Suite «увидит» его либо можно сразу приступать к MX-записям.

Создание WWW-домена

Как загрузить веб-сайт на сервер с ISPmanager

Сайт — страница или группа страниц, которые транслируются в интернет и доступны пользователям по URL-адресу. Внешний вид и содержимое сайта формируются из его исходных файлов. Чтобы добавить в ISPmanager сайт, перейдите в Домены → WWW-домены → Создать и укажите параметры создания.

Создать WWW-домен можно, только если установлен веб-сервер. Подробнее см. в статье Установка веб-сервера.

Данные о WWW-домене ISPmanager хранит в своей базе данных. Если вы измените их через форму Домены → WWW-домены → Изменить, ISPmanager обновит данные в базе. Если вы измените их вручную в конфигурационных файлах веб-серверов, то при открытии формы Домены → WWW-домены → Изменить ISPmanager отобразит предупреждение о несовпадении данных. При сохранении формы изменённые вручную параметры будут записаны в базу данных. Подробнее см. в статье Обработка ручных правок конфигурационных файлов веб-серверов.

Изменить настройки веб-сервера для WWW-домена вручную можно в Домены → WWW-домены → Конфиг. ISPmanager проверяет только синтаксис данных указанных вручную в конфигурационных файлах.

Читать еще:  Объединение разных доменных лесов в один

При добавлении WWW-домена для него автоматически создаётся доменное имя. Подробнее см. в статье Создание доменного имени.

Основные настройки

Укажите Имя WWW-домена .

В конфигурационном файле Nginx для WWW-домена добавляется строка:

В конфигурационном файле Apache для WWW-домена добавляется строка:

Укажите Псевдонимы — дополнительные имена, которые будут использоваться для доступа к WWW-домену. По умолчанию после ввода имени WWW-домена указывается псевдоним «www. «. Для псевдонима автоматически создастся ресурсная A-запись. Подробнее см. в статье Создание ресурсных записей доменной зоны.

В конфигурационном файле Nginx для WWW-домена в строке

добавляются псевдонимы WWW-домена:

В конфигурационном файле Apache для WWW-домена добавляется строка:

Укажите Корневую директорию сайта. В ней хранятся файлы сайта на сервере.

В конфигурационном файле Nginx для WWW-домена добавляются строки:

В конфигурационном файле Apache для WWW-домена добавляется строка:

Выберите систему для управления содержимым сайта (CMS) в поле Выбор скрипта. CMS используют для наполнения сайта содержимым (статьи, фотографии, страницы и т. п.) Без неё для добавления нового или изменения существующего содержимого потребуется редактировать исходные файлы сайта. ISPmanager поддерживает CMS Drupal, Prestashop, WordPress, joomla, phpBB.

Выберите Владельца WWW-домена — пользователя ISPmanager.

В /vhosts создаётся директория с логином пользователя. В этой директории создаётся конфигурационный файл Nginx для WWW-домена с названием вида .conf.

В /conf/vhosts создаётся директория с логином пользователя. В этой директории создаётся конфигурационный файл Apache для WWW-домена с названием вида .

указать вручную — IP-адрес можно выбрать в поле IP-адрес из списка добавленных в Настройки → IP-адреса.

В конфигурационном файле Nginx для WWW-домена добавляется строка:

В конфигурационном файле Apache для WWW-домена добавляется строка:

По умолчанию используются 80 порт для незащищённого соединения и 443 для защищённого.

Укажите E-Mail администратора — адрес электронной почты, который будет отображаться на страницах ошибок веб-сервера для WWW-домена.

В конфигурационном файле Apache для WWW-домена добавляется строка:

В конфигурационном файле Nginx для WWW-домена добавляется строка:

В конфигурационном файле Apache для WWW-домена добавляется строка:

Чтобы изменить список кодировок, создайте файл /usr/local/mgr5/etc/charset и укажите в нём нужные значения.

Укажите Индексную страницу сайта. Эта страница открывается у пользователя, который переходит на сайт по доменному имени и не указал конкретной страницы. Например, при запросе www.example.com или www.example.com/test вместо www.example.com/index.php. Можно указать несколько страниц в порядке убывания значимости через пробел. Если первой указанной страницы не существует, то будет проверяться наличие второй страницы и т. д.

В конфигурационном файле Nginx для WWW-домена добавляется строка:

В конфигурационном файле Apache для WWW-домена добавляется строка:

Включите опцию SSI, чтобы перед показом страниц сайта пользователю обрабатывались SSI-команды. SSI — язык программирования для динамической «сборки» страниц на сервере перед их показом.

В конфигурационном файле Nginx для WWW-домена добавляется строка:

В конфигурационном файле Apache для WWW-домена добавляется строка:

Если нужно, включите опцию Приоритетный. Используется, если на одном IP-адресе доступны несколько сайтов и пользователь запрашивает сайт по IP-адресу, а не доменному имени. В таком случае откроется приоритетный сайт. Если ни один сайт не указан приоритетным, откроется тот, доменное имя которого первое по алфавиту . При этом для кириллических доменов используются имена в кодировке punycode.

В конфигурационном файле Nginx для WWW-домена строка

В /conf/vhosts-default/ создаётся символическая ссылка на конфигурационный файл Apache для WWW-домена.

Если включить опцию Приоритетный, то проверяется наличие на IP-адресе, который указан для домена, уже существующего приоритетного домена. Если такой домен существует, то он перестанет быть приоритетным.

в отдельной директории — файлы поддоменов нужно создавать в поддиректориях /var/www/www-root/data/www/ с именем поддомена. Например, для поддомена www.test.example.com, корневая директория которого расположена в /var/www/www-root/data/www/example.com файлы поддоменов нужно создавать в /var/www/www-root/data/www/test.example.com.

В конфигурационном файле Nginx для WWW-домена добавляются строки вида:

В конфигурационном файле Apache для WWW-домена добавляется строка вида:

в поддиректории домена — файлы поддоменов нужно создавать в поддиректориях корневой директории сайта. Например, для поддомена www.test.example.com, корневая директория которого расположена в /var/www/www-root/data/www/example.com файлы поддоменов нужно создавать в /var/www/www- root /data/www/example.com/test.

В конфигурационном файле Nginx для WWW-домена добавляются строки вида:

В конфигурационном файле Apache для WWW-домена добавляется строка вида:

При выборе способа создания автоподдоменов «в отдельной директориии» или «в поддиректории домена» в поле Псевдонимы добавляется значение «*. «.

Возможность создания Автоподдоменов доступна, если опция Приоритетный отключена для домена .

Настройка защищённого соединения

Чтобы обезопасить данные, передаваемые между браузером пользователя и сайтом, включите опцию Защищённое соединение (SSL). Для защищённой передачи и шифрования данных используется протокол SSL. При этом требуется наличие сертификата для сайта.

В конфигурационном файле Nginx для WWW-домена создаётся вторая секция server. В ней добавляются строки вида:

В конфигурационном файле Apache для WWW-домена создаётся вторая секция server. В ней добавляются строки вида:

Настройте параметры защищённого соединения:

Включите опцию HSTS, чтобы при попытке открыть сайт по незащищённому соединению принудительно открывалось защищённое соединение. Перенаправление срабатывает, только если браузер пользователя уже подключался к сайту по защищённому соединению и запомнил это. При перенаправлении сервер возвращает код ответа «301 Moved Permanently».

В конфигурационном файле Nginx для WWW-домена добавляется строка:

В конфигурационном файле Apache для WWW-домена добавляются строки:

Включите опцию Перенаправлять HTTP-запросы в HTTPS, чтобы при попытке открыть сайт по незащищённому соединению принудительно открывалось защищённое соединение. Перенаправление срабатывает всегда. При перенаправлении сервер возвращает код ответа «301 Moved Permanently».

В конфигурационном файле Nginx для WWW-домена добавляется строка:

В конфигурационном файле Apache для WWW-домена добавляются строки:

Если нужно, измените SSL-порт. Он используется для открытия защищённого соединения. По умолчанию — «443».

Порт указывается в конфигурационном файле Nginx для WWW-домена в строке:

и в конфигурационном файле Apache для WWW-домена в строке:

Настройка защиты от DDoS-атак

Включение защиты доступно, только если установлен веб-сервер Nginx. Подробнее об установке см. в статье Установка веб-сервера.

Чтобы настроить блокировку IP-адресов, с которых поступает большое количество запросов , Включите защиту от DDOS-атаки. В блоке настроек Защита от DDoS-атаки укажите параметры защиты:

    Количество запросов в секунду — при превышении этого количества запросов от одного IP-адреса, он блокируется на 5 минут.

Максимальный размер всплеска — при превышении максимального количества запросов в секунду новые запросы блокируются.

Используется модуль ngx_http_limit_req_module. Подробнее см. в статье Настройка защиты от DDoS-атак.

Поддержка динамического содержимого

PHP-скрипты

Если для сайта нужна поддержка скриптов на языке PHP, включите опцию PHP и настройте его работу:

Выберите Режим работы PHP:

  1. модуль Apache — динамическое содержимое обрабатывает модуль PHP веб-сервера Apache.
  2. CGI — динамическое содержимое обрабатывает Apache в режиме CGI.
  3. FastCGI (Apache) — динамическое содержимое обрабатывает Apache в режиме FastCGI.
  4. FastCGI (Nginx + PHP-FPM) — динамическое содержимое обрабатывает PHP-FPM.
  • Для режимов «CGI» и «FastCGI (Apache)» выберите нужную версию PHP (CGI).
  • Для режима «модуль Apache» отключите опцию Использовать open_basedir, если нужно разрешить PHP-скриптам доступ ко всем директориям сервера. Если опция включена, доступ ограничен корневой директорией WWW-домена.
  • Подробнее см. в статье Режимы работы PHP.

    CGI-скрипты

    Если для сайта нужна поддержка CGI-скриптов, включите опцию CGI-скрипты и укажите Расширения файлов CGI-скриптов.

    Опция доступна, только если установлен веб-сервер Apache. Подробнее об установке см. в статье Установка веб-сервера.

    В конфигурационном файле Nginx для WWW-домена добавляются строки:

    В конфигурационном файле Apache для WWW-домена добавляются строки:

    Читать еще:  Домен на centos

    Настройка журналов

    Чтобы ISPmanager собирал статистику запросов к веб-серверу, включите опцию Журнал запросов.

    Выберите Генератор отчётов.

    Доступно, только если установлен веб-сервер Apache и модуль awstats или webalizer. Подробнее об установке см. в статье Установка веб-сервера.

    Укажите Период сбора статистики по запросам.

    Выберите Язык отчёта.

    Если нужно, включите опцию Ограничить доступ к статистике, укажите Пароль для доступа к статистике и его Подтверждение. В качестве логина будет использоваться имя владельца WWW-домена.

    Чтобы ISPmanager собирал статистику ошибок веб-сервера для WWW-домена, включите опцию Журнал ошибок.

    Выберите Период ротации журналов.

    В поле Хранить архивов укажите количество файлов журналов, которое будет храниться в заархивированном виде.

    В конфигурационном файле Nginx для WWW-домена добавляются строки вида:

    В конфигурационном файле Apache для WWW-домена добавляются строки вида:

    Как перенести сайт на новый хостинг за 6 шагов

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

    Просто расторгнуть один договор и заключить новый для смены площадки веб-ресурса недостаточно. Перенос сайта с одного хостинга на другой всегда связан с решением ряда технически сложных задач, многие из которых требуют взаимодействия со специалистами провайдера. В этой статье мы расскажем, как упростить процедуру «переезда» до 6 простых шагов.

    Шаг 1: добавляем домен

    Первое, что необходимо сделать для переноса сайта — добавить домен и прикрепить к нему папки, куда впоследствии загрузим файлы сайта.

    Простой способ зарегистрировать домен в одной из популярных зон — приобрести его в Eternalhost. Низкие цены и бесплатный DNS-хостинг.

    В панели управления ищем пункт с настройками имени. В нем можно зарегистрировать домен, либо перенести имеющийся со старого сервера. Нажимаем на «Добавить/Зарегистрировать домен» и вводим данные. Этот шаг не переносит имя на выбранный хостинг, а только лишь готовит аккаунт к подключению.

    Шаг 2: переносим файлы сайта

    Перед данным шагом рекомендуется сделать полную резервную копию сайта и проверить её на работоспособность. Это позволит исключить потери критически важной информации в процессе переноса.

    Сначала необходимо скачать всю информацию со старого хостинга. Её нужно взять из корневой директории сайта. Для скачивания можно использовать:

    • Протокол FTP/SFTP (FileZilla, FAR, Total Commander);
    • Протокол SSH (Putty);
    • Встроенный в панель управления хостингом менеджер файлов.

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

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

    Шаг 3: переносим базу данных

    Этот шаг относится к сайтам с CMS. Подобные системы управления, чаще всего работают на основе баз MySQL, которые тоже нужно переместить. Управлять базами данных (БД) можно с помощью веб-интерфейса, встроенного в панель управления хостингом или вручную, через панель phpMyAdmin.

    Для переноса MySQL нужно зайти в раздел, содержащий БД и выделить все файлы. Далее запускаем функцию «Экспорт» и выбираем путь для сохранения файлов. Как и в случае с файлами сайта, для экономии времени можно заранее создать архив.

    На новом хостинге выбираем функцию «Создание базы данных». Заполняем соответствующие поля, включая название БД, логин, пароль, после чего нажимаем кнопку «Создать».

    На завершающем этапе дампа баз данных необходимо загрузить БД на новый сервер. Для этого нажимаем на «Импорт». В появившемся окне вписываем путь к заранее сохранённому архиву и подтверждаем действие. После переноса нужно внести настройки подключения БД в конфигурационный файл сайта или CMS (см. Этап 5).

    Шаг 4: переносим учетные записи e-mail

    Этот шаг важен тем, кто активно использует в работе электронную почту. Варианты «почтовой» миграции зависят от изначальных сценариев использования данного канала связи:

    1. Адрес почты находится на регистраторе доменного имени. Самый удобный вариант. Для переноса учётных записей e-mail нужно просто зайти в аккаунт регистратора и привязать почтовый сервер на IP-адрес выбранного хостинга.
    2. Электронная почта привязана к сервису-посреднику (например, Microsoft 365, Google G Suite, МойОфис). В этом случае нужно проверить, обновляются ли в DNS записи MX, необходимые поставщику e-mail услуг.
    3. Адрес электронной почты размещенна сервере старого хостинг-провайдера. Тогда придется потратить время, чтобы заново создать учетные записи на новом хостинге. Для этого нужно воспользоваться функцией импорта e-mail в разделе «Электронная почта».

    Шаг 5: обновление файлов конфигурации CMS

    Необходимо изменить настройки в системном документе ресурса. Обычно это файл находится в папке с «движком» и имеет в своём названии слова «config», «conf», «settings». Например, на WordPress он называется «wp-config.php», на Bitrix «dbconn.php», а на Joomla «configuration.php».

    Ищем конфигурационный файл в сохранённом архиве с данными сайта и открываем в «блокноте». В строках со словами «Name», «User», «Password», «Host» прописываем всю свежую информацию. Когда конфигурация будет исправлена, устанавливаем файл в корень веб-сайта на новом сервере.

    Шаг 6: меняем DNS-сервер и переносим домен

    Последнее, что осталось сделать — подключить существующее доменное имя на новом сервере через измение настройки NS, где на текущий момент прописаны данные старого хостера.

    Поле серверов имён (NS) в панели биллинга на хостинге.

    Трансфер можно осуществить тремя способами:

    • полностью перенести домен к новому хостеру/регистратору;
    • изменить DNS-запись;
    • поменять Сервера имён (NS сервера) домена.

    Два первых способа связаны с рядом технических сложностей, поэтому остановимся на описании третьего варианта. Сначала нужно узнать новые значения NS серверов нового хостинга – они начинаются с букв «ns1», «ns2» и т.д. Обычно эта информация находится в памятке, присылаемой по почте при регистрации. Затем обновить эти значения на старом хостинге через панель управления доменом.

    Проверка сайта

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

    1. Сделать проверку через технический доменов ресурса. Обычно это адреса четвертого уровня, обеспечивающие работу страниц даже тогда, когда основное имя не функционирует.
    2. Проверить работу сайта через поддомен, подключённый к public_html.
    3. Заказать проверку работоспособности через техническую поддержку хостера.

    Заключение

    Следуя этому алгоритму, можно без особых трудностей сменить хостинг сайта самостоятельно. Если же своих сил и познаний в администрировании ресурса не хватает, всегда есть возможность запросить эту услугу у технической поддержки нового хостера. Провайдеры — и Eternalhost тут не исключение — охотно помогают клиентам с переездом. Достаточно создать обращение (тикет) через панель управления или написать на e-mail, как к решению технически сложных задач переноса сайта тут же подключатся профессионалы.

    Надо помнить, что процесс «переезда» сайта не проходит моментально. Системе потребуется время на обработку всех запросов о смене учетных записей. Полный перенос сайта на новый сервер может занять от пары часов до нескольких дней. В этот период лучше не вносить никаких изменений на веб-ресурс. И последнее — не забудьте удалить все данные сайта со старого хостинга, после успешного переезда.

    Ссылка на основную публикацию
    ВсеИнструменты
    Adblock
    detector