Skurudo Blog(post): заметки с тегом Яндекс

Импорт пользователей в Яндекс.Коннект через API

Thu, 04 Mar 2021 15:00:15 +0300

Возникла задача добавить несколько десятков пользователей в Яндекс.Коннект и сразу же начались поиски пути решения, чтобы избавиться от ручного труда и в дальнейшем облегчить жизнь. Решил попробовать вариант от Energys — статья на habr’e. Почему попробовать? За пару лет что-то могло перестать работать, как говорится — «За время пути собака могла подрасти!»

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

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

* зайти в аккаунт яндекса под администратором домена;
* в Я.OAuth первым делом нужно создать приложение;
* приложению даем права, в нашем случае — Яндекс.Коннект Directory API;
* выбираем платформу «веб-сервисы» и нажимаем «подставить url для разработки»;
* сохраняемся и получим ID приложения — именно оно понадобится для получения токене;
* вставляем ID приложения и получаем токен:

https://oauth.yandex.ru/authorize?response_type=token&client_id=<ID приложения>

* именно этот токен и будет использоваться в скрипте;

Идея сравнительно не сложная:

готовим файл определенного образца;
добавляем переменных;
читаем список из файла;
в запросе в цикле добавляем переменные;
в каждой итерации ждем пару секунд.

Сам скрипт выглядит следующим образом — он же на GitHub:

#!/bin/bash
# path to users list - путь к списку пользователей
employees='./usrlist'
# line example from users list - пример строки файла 
# usrlist: email_lastname_firstname_middlename_password_position
# for example: petrova_Петрова_Авдотья_Федоровна_eeKrutoiparol23_Менеджер

# OAuth_Token
# link to material about token - ссылка на формирование отладочного токена
# https://tech.yandex.ru/oauth/doc/dg/tasks/get-oauth-token-docpage/
# link about our apps - список ваших приложений
# https://oauth.yandex.ru/
# get token from apps id - получить токен из ID приложения
# https://oauth.yandex.ru/verification_code#access_token=435843755894374389
TOKEN="token-here-and-there"

# read and trim user file - читаем и перебираем файл со списком пользователей
for i in $( cat $employees ); do
value=($(echo $i | tr "_" " "))

# make variables for api request from file - заводим переменные для запроса из файла
email="${value[0]}"
lastname="${value[1]}"
firstname="${value[2]}"
middlename="${value[3]}"
password="${value[4]}"
position="${value[5]}"

# Make user for good - создаем сотрудника ради добра
# department = 1 for default - департамент 1 умолчанию
#only http answers, not full - только http ответы, не полный лог
curl -i -X POST -H 'Content-type: application/json' -d '{"department_id": 1, "position": "'$position'", "password": "'$password'", "nickname": "'$email'", "name": {"first": "'$firstname'", "last": "'$lastname'", "middle": "'$middlename'"}}' -H "Authorization: OAuth $TOKEN" 'https://api.directory.yandex.net/v6/users/' | grep HTTP
#full answers - полные ответы
#curl -i -X POST -H 'Content-type: application/json' -d '{"department_id": 1, "position": "'$position'", "password": "'$password'", "nickname": "'$email'", "name": {"first": "'$firstname'", "last": "'$lastname'", "middle": "'$middlename'"}}' -H "Authorization: OAuth $TOKEN" 'https://api.directory.yandex.net/v6/users/' 
# wait for 2 sec - ждем пару секунд
wait 2
done

C чем удалось столкнуться при отладке и работе скрипта? Буквально несколько моментов:

* если посылать запросы слишком часто, часть может не сработать — нужно подбирать тайминги между запросами.. пауза в 1-2 секунды работает;
* обязательно нужно смотреть на входные данные — аккуратность с символами в названиях важна;
* моя частая ошибка — 422 Unprocessable Entity — при разборе оказалось, что пароль был слишком простой;

В поисках хостинга DNS

Wed, 27 Mar 2019 15:37:01 +0300

В далеком 2011 году впервые озаботился вопросом выбора DNS хостинга, чтобы был понадежнее да поудобнее. С тех пор обращался к теме поиска несколько раз, но ничего идеального так и нет. Основная претензия к такого рода услугам — она либо дорогая, либо неудобная, либо все вместе. Складывается ощущение, что те, кто занимается разработкой или руководит внедрением, не имеют у себя с десяток доменов или в DNS им нужно поменять что-то такое специфическое один раз, к одному домену и происходит это раз в сто лет и можно немного потерпеть. Не скажу, что сам меняю что-то каждый день, но некоторая частота все-таки есть. Еще один случай из клинических — переезд. Сменить одну А-запись для одного домена не долго, а вот когда там еще TXT и для доменов 3-его и 4-ого уровня? Довольно продолжительно по времени получается.

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

Чего бы сейчас хотелось от DNS хостинга:

если сервис платный, то стоимость поддержки не должна быть астрономически высокой;
серверы в нескольких гео-распределенных датацентрах поближе к магистральным каналам (на данный момент не самый критичный пункт, хотя несколько лет назад для меня это было важно — достаточно чтобы физически не в одном ДЦ);
«быстрый» пинг (желательно до 10 мс, в идеале 1-5 мс);
оперативная синхронизация между серверами;
поддержка NS, A, AAAA, CNAME, MX, TXT, PTR и SRV;
возможность изменения TTL по записям;
возможность изменения SOA по домену;
желательна поддержка DNSSEC;
поддержка Round Robin желательна;
возможность использования темплейтов (наличие инструмента или шаблона для создания — т. е. мы создаем шаблон с нужными записями и применяем его к домену);
возможность массовой правки записей по домену (к примеру мы выделили несколько записей и хотим из удалить или мы выделили несколько записей одного типа — А-запись к примеру и хотим поменять там значение IP)
возможность массовой правки записей по нескольким доменам (похоже для записи выше, здесь по большей части нас интересуют поля А-записей, TXT, SOA);
и конечно стабильная работа, высокий аптайм как всегда.

План миграции почтового сервера

Tue, 02 May 2017 20:15:02 +0300

Есть ли у вас план, мистер Фикс? ... Да у меня целых три плана!

Самый первый вопрос — организационный, руководство должно быть морально готово к переезду; нужно дать сроки по переезду, примерный план миграции, возможные риски, представить выгоды переезда. Если у вас нет полномочий для решения вопроса, лучше не начинайте делать что-то втихую.

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

Третий вопрос — подготовительный: структуру и будущих пользователей лучше всего завести заранее.

Четвертый вопрос — тестовая синхронизация, можно сделать на части пользователей. К примеру у меня была история, когда imapsync не синхронизировал вложенные папки, нужно было подбирать параметры.

Пятый вопрос — синхронизация данных, её можно и нужно в зависимости от объемов корреспонденции проводить не один раз, чтобы не потерять данные.

Шестой вопрос — переключение почтовых реквизитов у клиента, если вопрос не удалось решить в DNS.

Такой вот не хитрый план.

Странные проблемы с Google DNS

Sat, 26 Dec 2015 21:33:04 +0300

Сегодня где-то в половине шестого начались странные проблемы с интернетом. По цепочке проверили все, что только можно, пока не уперлись в dns от Google. Порядка трех часов из сети Ростелекома, с М9 и из сети Билайн было не получить ответа. Фокус в том, что пинги проходили нормально (потери были, но небольшие и непостоянные), а вот ответ не отдавался или отдавался с большими потерями. Забавное в том, что началось все с основного 8.8.8.8. Резервный адрес 8.8.4.4 работал нормально, правда потом начал хандрить и он.

Что это такое было не ясно, но больше всего сообщений мной было найдено из РФ. В англоязычном части интернета авария прошла незаметно (впрочем может её там и не было). Никаких официальных ответов или сведений об этом инциденте нет.

Проверять можно следующим образом:

nslookup google.com 8.8.8.8

dig @8.8.8.8 google.com

В качестве резерва есть днс серверы от Яндекса:

77.88.8.8
77.88.8.1

UPDATE, 22:00 — подборка новостей по теме:

КАЗАХТЕЛЕКОМ заблокировал DNS 8.8.8.8