{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Skurudo Blog(post): заметки с тегом Яндекс",
    "_rss_description": "«Я́ндекс» — российская ИТ-компания, владеющая одноимённой системой поиска в Сети и интернет-порталом",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/skurudo.ru\/tags\/yandex\/",
    "feed_url": "https:\/\/skurudo.ru\/tags\/yandex\/json\/",
    "icon": "https:\/\/skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083",
    "authors": [
        {
            "name": "Pavel Galkin",
            "url": "https:\/\/skurudo.ru\/",
            "avatar": "https:\/\/skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083"
        }
    ],
    "items": [
        {
            "id": "227",
            "url": "https:\/\/skurudo.ru\/all\/import-users-to-yandex-connect\/",
            "title": "Импорт пользователей в Яндекс.Коннект через API",
            "content_html": "<p>Возникла задача добавить несколько десятков пользователей в Яндекс.Коннект и сразу же начались поиски пути решения, чтобы избавиться от ручного труда и в дальнейшем облегчить жизнь. Решил попробовать вариант от <a href=\"https:\/\/habr.com\/ru\/users\/Energys\/\">Energys<\/a> — статья на <a href=\"https:\/\/habr.com\/ru\/post\/448036\/\">habr’e<\/a>. Почему попробовать? За пару лет что-то могло перестать работать, как говорится — «За время пути собака могла подрасти!»<\/p>\n<p>С первого взгляда не понравилось то, что пароли у сотрудников будущих одинаковые — это обязательно нужно было поменять, плюс не указана должность — потребовалось добавить. Однако для общего понимания статья подходит как нельзя лучше. К тому же изменения сравнительно не сложные — готовимся и применяем.<\/p>\n<p>Самое не простое в этой истории — возня с токеном от Яндекса. В статье она описана, пройдем по шагам для истории и чтобы ничего не забыть:<\/p>\n<ul>\n<li>* зайти в аккаунт яндекса под администратором домена;<\/li>\n<li>* в <a href=\"https:\/\/oauth.yandex.ru\/\">Я.OAuth<\/a> первым делом нужно создать приложение;<\/li>\n<li>* приложению даем права, в нашем случае — Яндекс.Коннект Directory API;<\/li>\n<li>* выбираем платформу «веб-сервисы» и нажимаем «подставить url для разработки»;<\/li>\n<li>* сохраняемся и получим ID приложения — именно оно понадобится для получения токене;<\/li>\n<li>* вставляем ID приложения и получаем токен:<\/li>\n<\/ul>\n<pre class=\"e2-text-code\"><code class=\"\">https:\/\/oauth.yandex.ru\/authorize?response_type=token&amp;client_id=&lt;ID приложения&gt;<\/code><\/pre><ul>\n<li>* именно этот токен и будет использоваться в скрипте;<\/li>\n<\/ul>\n<p>Идея сравнительно не сложная:<\/p>\n<ol start=\"1\">\n<li>готовим файл определенного образца;<\/li>\n<li>добавляем переменных;<\/li>\n<li>читаем список из файла;<\/li>\n<li>в запросе в цикле добавляем переменные;<\/li>\n<li>в каждой итерации ждем пару секунд.<\/li>\n<\/ol>\n<p>Сам скрипт выглядит следующим образом — он же на <a href=\"https:\/\/github.com\/skurudo\/usefulbash\/blob\/main\/yandex-connect-mass-user-add.sh\">GitHub<\/a>:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">#!\/bin\/bash\r\n# path to users list - путь к списку пользователей\r\nemployees=&#039;.\/usrlist&#039;\r\n# line example from users list - пример строки файла \r\n# usrlist: email_lastname_firstname_middlename_password_position\r\n# for example: petrova_Петрова_Авдотья_Федоровна_eeKrutoiparol23_Менеджер\r\n\r\n# OAuth_Token\r\n# link to material about token - ссылка на формирование отладочного токена\r\n# https:\/\/tech.yandex.ru\/oauth\/doc\/dg\/tasks\/get-oauth-token-docpage\/\r\n# link about our apps - список ваших приложений\r\n# https:\/\/oauth.yandex.ru\/\r\n# get token from apps id - получить токен из ID приложения\r\n# https:\/\/oauth.yandex.ru\/verification_code#access_token=435843755894374389\r\nTOKEN=&quot;token-here-and-there&quot;\r\n\r\n# read and trim user file - читаем и перебираем файл со списком пользователей\r\nfor i in $( cat $employees ); do\r\nvalue=($(echo $i | tr &quot;_&quot; &quot; &quot;))\r\n\r\n# make variables for api request from file - заводим переменные для запроса из файла\r\nemail=&quot;${value[0]}&quot;\r\nlastname=&quot;${value[1]}&quot;\r\nfirstname=&quot;${value[2]}&quot;\r\nmiddlename=&quot;${value[3]}&quot;\r\npassword=&quot;${value[4]}&quot;\r\nposition=&quot;${value[5]}&quot;\r\n\r\n# Make user for good - создаем сотрудника ради добра\r\n# department = 1 for default - департамент 1 умолчанию\r\n#only http answers, not full - только http ответы, не полный лог\r\ncurl -i -X POST -H &#039;Content-type: application\/json&#039; -d &#039;{&quot;department_id&quot;: 1, &quot;position&quot;: &quot;&#039;$position&#039;&quot;, &quot;password&quot;: &quot;&#039;$password&#039;&quot;, &quot;nickname&quot;: &quot;&#039;$email&#039;&quot;, &quot;name&quot;: {&quot;first&quot;: &quot;&#039;$firstname&#039;&quot;, &quot;last&quot;: &quot;&#039;$lastname&#039;&quot;, &quot;middle&quot;: &quot;&#039;$middlename&#039;&quot;}}&#039; -H &quot;Authorization: OAuth $TOKEN&quot; &#039;https:\/\/api.directory.yandex.net\/v6\/users\/&#039; | grep HTTP\r\n#full answers - полные ответы\r\n#curl -i -X POST -H &#039;Content-type: application\/json&#039; -d &#039;{&quot;department_id&quot;: 1, &quot;position&quot;: &quot;&#039;$position&#039;&quot;, &quot;password&quot;: &quot;&#039;$password&#039;&quot;, &quot;nickname&quot;: &quot;&#039;$email&#039;&quot;, &quot;name&quot;: {&quot;first&quot;: &quot;&#039;$firstname&#039;&quot;, &quot;last&quot;: &quot;&#039;$lastname&#039;&quot;, &quot;middle&quot;: &quot;&#039;$middlename&#039;&quot;}}&#039; -H &quot;Authorization: OAuth $TOKEN&quot; &#039;https:\/\/api.directory.yandex.net\/v6\/users\/&#039; \r\n# wait for 2 sec - ждем пару секунд\r\nwait 2\r\ndone<\/code><\/pre><p>C чем удалось столкнуться при отладке и работе скрипта? Буквально несколько моментов:<\/p>\n<ul>\n<li>* если посылать запросы слишком часто, часть может не сработать — нужно подбирать тайминги между запросами.. пауза в 1-2 секунды работает;<\/li>\n<li>* обязательно нужно смотреть на входные данные — аккуратность с символами в названиях важна;<\/li>\n<li>* моя частая ошибка — 422 Unprocessable Entity — при разборе оказалось, что пароль был слишком простой;<\/li>\n<\/ul>\n",
            "date_published": "2021-03-04T15:00:15+03:00",
            "date_modified": "2021-05-21T10:15:44+03:00",
            "tags": [
                "api",
                "bash",
                "почта",
                "скрипт",
                "Яндекс"
            ],
            "_date_published_rfc2822": "Thu, 04 Mar 2021 15:00:15 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "227",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "199",
            "url": "https:\/\/skurudo.ru\/all\/looking-for-dns-hosting\/",
            "title": "В поисках хостинга DNS",
            "content_html": "<p>В далеком 2011 году впервые озаботился вопросом выбора DNS хостинга, чтобы был понадежнее да поудобнее. С тех пор обращался к теме поиска несколько раз, но ничего идеального так и нет. Основная претензия к такого рода услугам — она либо дорогая, либо неудобная, либо все вместе. Складывается ощущение, что те, кто занимается разработкой или руководит внедрением, не имеют у себя с десяток доменов или в DNS им нужно поменять что-то такое специфическое один раз, к одному домену и происходит это раз в сто лет и можно немного потерпеть. Не скажу, что сам меняю что-то каждый день, но некоторая частота все-таки есть. Еще один случай из клинических — переезд. Сменить одну А-запись для одного домена не долго, а вот когда там еще TXT и для доменов 3-его и 4-ого уровня? Довольно продолжительно по времени получается.<\/p>\n<p>Помнится, был сначала YPDNS, более всего близок по <a href=\"https:\/\/old.skurudo.ru\/oldposts\/v-poiskah-hostinga-dns.html\">первоначальным требованиям<\/a>, но просуществовал недолго и закрылся. Если не изменяет память, то у создателя не оставалось времени и мотивации на продолжение ведения этого дела. Пришлось по большей части смигрировать на PDD от Яндекс, однако после миграции всего в Connect я начинаю думать, что Яндекс тоже идет по какому-то своему пути и интересы у нас немного разные.<\/p>\n<p>Чего бы сейчас хотелось от DNS хостинга:<\/p>\n<ol start=\"1\">\n<li>если сервис платный, то стоимость поддержки не должна быть астрономически высокой;<\/li>\n<li>серверы в нескольких гео-распределенных датацентрах поближе к магистральным каналам (на данный момент не самый критичный пункт, хотя несколько лет назад для меня это было важно — достаточно чтобы физически не в одном ДЦ);<\/li>\n<li>«быстрый» пинг (желательно до 10 мс, в идеале 1-5 мс);<\/li>\n<li>оперативная синхронизация между серверами;<\/li>\n<li>поддержка NS, A, AAAA, CNAME, MX, TXT, PTR и SRV;<\/li>\n<li>возможность изменения TTL по записям;<\/li>\n<li>возможность изменения SOA по домену;<\/li>\n<li>желательна поддержка DNSSEC;<\/li>\n<li>поддержка Round Robin желательна;<\/li>\n<li>возможность использования темплейтов (наличие инструмента или шаблона для создания — т. е. мы создаем шаблон с нужными записями и применяем его к домену);<\/li>\n<li>возможность массовой правки записей по домену (к примеру мы выделили несколько записей и хотим из удалить или мы выделили несколько записей одного типа — А-запись к примеру и хотим поменять там значение IP)<\/li>\n<li>возможность массовой правки записей по нескольким доменам (похоже для записи выше, здесь по большей части нас интересуют поля А-записей, TXT, SOA);<\/li>\n<li>и конечно стабильная работа, высокий аптайм как всегда.<\/li>\n<\/ol>\n",
            "date_published": "2019-03-27T15:37:01+03:00",
            "date_modified": "2019-03-27T15:40:40+03:00",
            "tags": [
                "DNS",
                "Яндекс"
            ],
            "_date_published_rfc2822": "Wed, 27 Mar 2019 15:37:01 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "199",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "165",
            "url": "https:\/\/skurudo.ru\/all\/migration-plan-of-the-mail-server\/",
            "title": "План миграции почтового сервера",
            "content_html": "<p>Есть ли у вас план, мистер Фикс? ... Да у меня целых три плана!<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/e3iMYTeUGaQ?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<ul>\n<li>Самый первый вопрос — организационный, руководство должно быть морально готово к переезду; нужно дать сроки по переезду, примерный план миграции, возможные риски, представить выгоды переезда. Если у вас нет полномочий для решения вопроса, лучше не начинайте делать что-то втихую.<\/li>\n<\/ul>\n<ul>\n<li>Второй вопрос — выбираем маршрут и пассажиров: нужно определиться, кто едет, в какую очередь, когда.<\/li>\n<\/ul>\n<ul>\n<li>Третий вопрос — подготовительный: структуру и будущих пользователей лучше всего завести заранее.<\/li>\n<\/ul>\n<ul>\n<li>Четвертый вопрос — тестовая синхронизация, можно сделать на части пользователей. К примеру у меня была история, когда imapsync не синхронизировал вложенные папки, нужно было подбирать параметры.<\/li>\n<\/ul>\n<ul>\n<li>Пятый вопрос — синхронизация данных, её можно и нужно в зависимости от объемов корреспонденции проводить не один раз, чтобы не потерять данные.<\/li>\n<\/ul>\n<ul>\n<li>Шестой вопрос — переключение почтовых реквизитов у клиента, если вопрос не удалось решить в DNS.<\/li>\n<\/ul>\n<p>Такой вот не хитрый план.<\/p>\n",
            "date_published": "2017-05-02T20:15:02+03:00",
            "date_modified": "2017-05-02T20:14:52+03:00",
            "tags": [
                "zimbra",
                "работа",
                "сервер",
                "Яндекс"
            ],
            "image": "https:\/\/skurudo.ru\/pictures\/remote\/youtube-e3iMYTeUGaQ-cover.jpg",
            "_date_published_rfc2822": "Tue, 02 May 2017 20:15:02 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "165",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/jquery\/jquery.js",
                    "system\/library\/media-seek\/media-seek.js"
                ],
                "og_images": [
                    "https:\/\/skurudo.ru\/pictures\/remote\/youtube-e3iMYTeUGaQ-cover.jpg"
                ]
            }
        },
        {
            "id": "136",
            "url": "https:\/\/skurudo.ru\/all\/strange-problems-with-google-dns\/",
            "title": "Странные проблемы с Google DNS",
            "content_html": "<p>Сегодня где-то в половине шестого начались странные проблемы с интернетом. По цепочке проверили все, что только можно, пока не уперлись в dns от Google. Порядка трех часов из сети Ростелекома, с М9 и из сети Билайн было не получить ответа. Фокус в том, что пинги проходили нормально (потери были, но небольшие и непостоянные), а вот ответ не отдавался или отдавался с большими потерями. Забавное в том, что началось все с основного 8.8.8.8. Резервный адрес 8.8.4.4 работал нормально, правда потом начал хандрить и он.<\/p>\n<p>Что это такое было не ясно, но больше всего сообщений мной было найдено из РФ. В англоязычном части интернета авария прошла незаметно (впрочем может её там и не было). Никаких официальных ответов или сведений об этом инциденте нет.<\/p>\n<p>Проверять можно следующим образом:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">nslookup google.com 8.8.8.8<\/code><\/pre><pre class=\"e2-text-code\"><code class=\"\">dig @8.8.8.8 google.com<\/code><\/pre><p>В качестве резерва есть днс серверы от Яндекса:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">77.88.8.8\r\n77.88.8.1<\/code><\/pre><p><b>UPDATE, 22:00 — подборка новостей по теме<\/b>:<\/p>\n<ul>\n<li><a href=\"https:\/\/sku.su\/uLXUV\">Тостер, 19:15<\/a><\/li>\n<li><a href=\"https:\/\/sku.su\/d2aFo\">Twitter, 19:23<\/a><\/li>\n<li><a href=\"https:\/\/sku.su\/UKsZp\">Хабрахабр, 19:51<\/a><\/li>\n<li><a href=\"https:\/\/sku.su\/uLXUV\">Тостер, 19:57<\/a><\/li>\n<li><a href=\"https:\/\/sku.su\/yVEsg\">ЖЖ m0z9s, 20:12<\/a><\/li>\n<li><a href=\"https:\/\/sku.su\/ZCiiL\">Тостер, 20:45<\/a><\/li>\n<li><a href=\"https:\/\/sku.su\/dytrN\">Roem, 21:17<\/a><\/li>\n<\/ul>\n<ul>\n<li><a href=\"https:\/\/sku.su\/McYsT\">КАЗАХТЕЛЕКОМ заблокировал DNS 8.8.8.8<\/a><\/li>\n<\/ul>\n",
            "date_published": "2015-12-26T21:33:04+03:00",
            "date_modified": "2015-12-26T22:06:37+03:00",
            "tags": [
                "DNS",
                "Google",
                "авария",
                "Яндекс"
            ],
            "_date_published_rfc2822": "Sat, 26 Dec 2015 21:33:04 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "136",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4116,
    "_e2_ua_string": "Aegea 11.2 (v4116)"
}