Проблемы REST API или Яндекс тоже лажает

Вчера заметил лажу Яндекса в реализации REST API и решил немного высказаться про идеологов правильного использования REST.

Под данными идеологами я понимаю людей, которые месяцами выбирают HTTP-метод (PUT или PATCH? Сложный выбор!), вылизывают урлы (так, /user/add/group или /group/add/user, или POST /, а остальное данными?), при этом по факту никому их API никогда не нужно, а если и нужно то используется через врапперы и библиотеки.

Красивые урлы и семантика, конечно, важна, но проблема в том, что REST работает через HTTP со своими заморочками и ограничениями. Например, в GET нельзя закидывать body, и надо пытаться засунуть всё в URL, а если не влезает, то сделать POST, получить ID запроса, и сделать GET. Идиотизм. зато семантично.

Или моё любимое: по стандарту GET-ответы кешируются, если не сказано иное (хотя хрому наплевать на это). Звучит разумно, например, мы получаем текущую фазу луны, никаких параметров, она всегда одинаковая, хотя... стоп... Давайте что-нить попроще, например количество входящих сообщений пользователя... блин... Пол пользователя! Во! Главное, чтобы он к врачу не сходил. В общем, если умерить сарказм, то получается, что GET-запросы для API практически никогда не надо кешировать, ибо хоть они и получают данные, но те данные имеют тенденцию меняться в самый непредсказуемый момент.

Решений для убирания кешироания несколько:

• С сервера посылать запрет кеширования. Работает, но несемантично
• К каждому запросу подсовывать рандомную строку. Работает, но выглядит ужасно и по факту засираем кеш браузера
• Переделать API так, чтобы в нём участвовала рандомная строка. Например, дать количество сообщений пользователя на определённую дату. Пофиг, что кроме текущей мы ничего не можем сделать, зато прикрутили параметр
• Делать POST, а потом GET - очень глупо, медленно, неудобно, но семантично

В общем, вместо того, чтобы тупо сделать всё на POST'ах, мы активно боремся с инфраструктурой. И подобные проблемы периодически возникают то тут, то там. И борьба с ними идёт в основном ради красоты.

К чему всё это я — моё мнение, если вы не пишете могучее API для использования миллионами людей, то и не парьтесь, а если пишете — то сделайте SDK для него, и тоже не парьтесь. И все будут счастливы, кроме горстки перфекционистов.

Собственно, а что с Яндексом? Дело в том, что недавно они написали умную статью, о том как работать с HTTP, типа учитесь как правильно. Ок, поучился. Захожу на internet.yandex.ru и вижу картину следующего вида:

Естественно, со временем всё было в порядке. Просто я обновил данную страницу в браузере, а запрос о времени, сделанный по всем правилам Яндекса по урлу http://yandex.ru/internet/api/v0/datetime/ не имел никаких параметров кеширования. Что привело к тому, что браузер честно отдал ответ, который он запомнил 6 часов назад.
Как видите, Яндекс умеет делать красиво, рассказывать всем как правильно, только выкатывает в итоге нерабочий сервис.

UPD: Увидел ссылку, которая описывает архитектурные проблемы REST чуть в другом ключе, но пересекается с данным постом и я с ней в целом согласен. Также, могу сказать, что в одном из проектов я использовал JSON-pure API, и с ним не было никаких проблем. Данный код до сих пор бродит по разным проектам и не вызывает нареканий.

Чудесатые интернеты

Решил написать про бредовую ситуацию, с которой я сегодня столкнулся. Связана она была с настройкой виртуалки в Амстердаме у Infobox.

Итак, есть виртуалка, вроде бы всё работает, но при попытке достучаться по самбе, получаю ошибку. Фактически, блокируются 135, 139 и 445-ые порты. Я поплясал с бубном, помучал фаирвол, всё бестолку. В конце-концов, решил проверить доступ с внешней машины. Он был. В полном офигении, я начал копать проблему дальше, и выяснил следующие факты

1. Любой порт кроме этих трёх работает корректно
2. Эти три порта работают корректно из любой доступной мне сети (и интернет-утилит), кроме рабочей
3. Из рабочей сети доступ на данные порты на другие внешние сервисы открыт и работает
4. Никаких запретов на подобное во внутренней сети нет

Т.е., фактически получается, что или провайдер, или хостер рубят эти три порта, именно для нашей сети или для сети хостера. Совершенно безумная ситуация, которая по идее невозможна, а если возможна, то кто-то ведёт себя очень плохо.

Есть, конечно, другой вариант. Он заключатся в том, что я таки сошёл с ума, и мне всё это кажется. С учётом бредовости ситуации, этот вариант допустим.

Вот так, блин, и работаем.

UPD: Оказалось, что это посредник Инфобокса блокирует часть портов, почему-то считая именно эти "небезопасными". Причём, блокирует только с части сетей. Признались они только после длительной переписки с саппортом.

Управление виртуалками для обычных пользователей в Hyper-V 2012 R2

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

В своё время, Microsoft выпустила сервер виртуализации Hyper-V, весьма неплохой, хоть и со своими тараканами. И там можно было сделать замечательную вещь: выдать пользователю права на виртуалку, которая крутится на сервере. Т.е. он мог её включать, выключать, дёргать у неё сеть, но при этом, он постоянно к ней подключён, и в тоже время не видит соседей.

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

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

Зато, после всех этих мучений, можно было весьма гранулированно раздавать права через AzMan (я, кстати, первый раз его видел, хотя, судя по всему, существовал в системе давно, с XP. Но мы-то знаем, что Microsoft не ищет лёгких путей и всегда есть по крайней мере три несовместимых технологии).

К сожалению, в 2012 R2, эта магия больше не работает. Всё сломано. Мне понадобилось достаточно длительное время, чтобы понять это, т.к. народ умудряется писать статьи о том, что всё таки работает. Не работает. Проверено. С большим скрежетом, я всё-таки нашёл, что можно с этим сделать. А сделать можно только одно: давать пользователю подключаться, к виртуальной машине. Т.е. включить он её не может, но хотя бы может работать с ней. Для того, чтобы как-то добавить права, судя по всему нужна отдельная прослойка, которая со своими жирными правами будет всё делать, уже сам раздавая права. Данной прослойкой может быть System Center Virtual Machine Manager или что-то своё самописное (можно добавить имперсонацию и рулить юзерами, действия тупо выполнять через PowerShell). Но само подключение можно реализовать чуть проще, хотя и не очень очевидно.

Собственно, для возможности подключения пользователя (не админа) к определённой виртуалке надо сделать следующее):

1. Выдать права на виртуалку через PowerShell
   Grant-VMConnectAccess -ComputerName host_name -VMName vm_name -UserName user_name
   Есть ещё команды Get-VMConnectAccess для просмотра прав и Revoke-VMConnectAccess для отбирания
2. В PowerShell выяснить id-нужной нам виртуалки
   Get-VM -ComputerName host_name | select id,name
3. Установить Remote Desktop Connection Manager (стандартный не катит)
4. В нём сделать новую группу, в группу добавить сервер, на вкладке Server Settings поставить VM Console Connect, ввести нужный Id и сохранить всё это дело

После этого можно пользоваться прямым подключением к виртуалке (возможно придётся открыть ещё порт 2179).

В общем, как-то так. Если как-то всё-таки можно подключиться через стандартный клиент, напишите в комментариях, буду очень признателен.

Ещё одна проблема HttpWebReqest

Я уже писал про грабли HttpWebRequest, но тут нашёл ещё одну забавную, и местами неприятную. Правда наполовину она относится к HttpWebResponse, но классы связаны метровым канатом, так что не принципиально.
Вкратце: работа с куками организована очень оригинально, и не очень логично.

Для удобства распишу по условным пунктам. Для начала диспозиция:

• Сервер возвращает куки в Http-заголовке Set-Cookie
• Если надо установить две куки, сервер передаёт два заголовка (не очень логично, но ок)
• HttpWebResponse имеет пропертю Headers, и по имени заголовка можно получить значение

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

Но! У Headers можно взять значения через .GetValues(), вернётся честный массив из двух элементов. И вроде бы всё хорошо, и пост можно жакончить, но тут приходит сервер, и выдаёт нам:

Set-Cookie: ABC=123; expires=Fri, 31 Dec 2010 23:59:59 GMT; path=/;

Вы заметили, что между пятницей и 31-ым числом есть запятая? HttpWebResponse тоже заметил, и вместо этой куки честно вернул нам две, обе разломанные. Всё, приехали.

Но обойти это надо, поэтому можно сделать следующие вещи:

• Вручную распарсить значения кук, зная, что запятая, по стандарту, запрещённый символ. Т.е. встретится она может только в expires
• Взять у HttpWebResponse пропертю Cookies, с уже обработанными куками

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

request.CookieContainer = new CookieContainer()

Немного нелогично (нам ведь только ответные нужны), но в принципе допустимо. И всё из-за весьма странной реализации работы с заголовками.

На этом всё, буду ловить очередные грабли данного класса. 

Немного про починку винды через много букв

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

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

Винда, с трудом но поднялась после всего этого, правда для этого пришлось починить несколько важных для загрузки файлов и собрать монстра из реестра (комбинация из встроенного бекапа в C:\Windows\System32\config\RegBack\ и основного реестра), но в общем-то фатальных проблем не было.
Правда при работе слегка глючила, не давала подключиться удалённо, плюс были ещё мелкие и не очень проблемы (некоторые выявились только спустя несколько месяцев).
Что можно с этим сделать, и как чинить?

Вариант 1. Апгрейд винды на саму себя из установочных файлов

Винда бережно сохраняет все настройки и восстанавливает их в новой системе. Но есть проблема, могут сохраниться ошибочные настройки, а часть данных не перенесётся, причём лучше уж поломанный сервис, который ты знаешь, что надо починить, чем рабочий, у которого потерялась какая-то хитрая настройка, и из-за этого он поведёт себя не так как надо.
Так что этот способ не очень хорош, кроме того требует некоторого даунтайма системы (на установку и настройку сервисов снова). У меня был один такой системный сервис, который очень не хотелось трогать (и да, он разваливается при переустановке, можно поднять его из бекапа, и потом донастроить).
Так что я пробовал другие способы

Вариант 2. sfc /scannow

Способ, который рекомендуют на всех форумах, к сожалению помогает он плохо, т.е. ничего не лечит (ему неоткуда взять корректные файлы при серьёзных повреждениях), но зато создаёт логи в C:\Windows\Logs\CBS\CBS.log, с помощью которых можно узнать повреждённые файлы и физически заменить их с аналогичной системы (тут очень помогает Far, который достаточно вольно относится к отсутствию прав на файлы (т.е. если есть права выдать себе права, но в данный момент их нет, а приказ что-то сделать с файлом есть, фар решит эту проблему самостоятельно). Без фара можно ручками выдавать права на проблемные файлы, меняя владельца с TrustedInstaller на себя и раздавая права (если хочется красоты, следующий запуск sfc /scannow всё починит).
Таким образом я починил большинство проблем и система жила, пока не потребовалось ещё кое-что настроить.
Но для начала

Вариант 3. dism

Утверждается, что свежая винда может себя починить через следующую команду:

DISM.exe /Online /Cleanup-image /Restorehealth

или

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess

Первый способ обещает починить файлы через Windows Update, второй использует локальное хранилище в случае невозможности подключиться.

Вкратце: способ мне не помог, хотя что-то делал и явных ошибок работы не выдавал. Тем не менее, он много каши не просит, поэтому стоит его попробовать.

---

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

Итак, на первый взгляд проблемы появились в том, что не ставились апдейты. Изучение ошибок и логов привело к парадоксальному результату: они не ставились, потому что валился Task Scheduler со статусом что-то типа Initialize::UserTable (за точность ошибки не ручаюсь, ибо по памяти). Т.е. совершенно невменяемая ошибка. Были перепробованы все средства, пока не оказалось, что проблема в том, что в управлении пользователями отсутствовали локальные пользователи, а при открытии групп вылезало две ошибки с чтением данных. Т.е. проблема не в этом, а в том что есть именно проблема с пользователями. При этом из консоли (net user, net localgroup) проблем явных не было.

Тут я полез уже в дебри и выяснил следующее:
Вся информация о пользователях хранится в ветке реестра SAM, которая в реестре замаплена на HKEY_LOCAL_MACHINE\SAM. Если вы откроете ветку сейчас, вы ничего там не увидите. Рекомендую добавить себе права.
Там всё внутри устроено оригинально и не так как в остальном реестре. В частности, есть группы пользователей (SAM\Domains\Account\Aliases) и сами локальные пользователи (SAM\Domains\Account\Users). Они идентифицируется неким id, а сопоставление имён и id идёт в отдельном разделе (SAM\Domains\Account\Users\Names\), где в качестве типа указан данный id. Т.е. не значение, а тип. который обычно DWORD, STRING, BINARY. Впрочем, это можно списать на особенности отображения и то, что этот раздел не предназначен для обычных глаз.
У пользователей есть бинарные параметры F и V, а у групп С, которые содержат описание объекта, SIDы, и кто кому принадлежит.
В моём случае, были повреждены разделы C (их тупо не было) у групп администраторов и пользователей, и был один повреждённый пользователь (хотя визуально он был в порядке.
Эти проблемы и вызывали странное поведение в управлении пользователями.
Если хочется тут что-то сделать, вначале делаем бекап, потом играемся как хотим. У нас есть возможность откатиться.
Эмпирическим путём проблемный пользователь был вычислен и уничтожен (удалением ветки реестра), пользователи вернулись в норму. Раздел C, был импортирован с соседнего компьютера и всё ожило (Планировщик, а вместе с ним и апдейты. То ли у них были проблемы с группами, то ли с пользователем). К сожалению, в управлении группами в этих группах появились неизвестные SIDы (неудивительно, с таким-то импортом), которые не удалялись, а также не добавлялись новые пользователи.

Наилучшим решением проблемы я посчитал следующее (очень не хотелось разбираться в бинарной структуре данных записей, не стоит оно того). Например, у нас проблемная группа Administrators. Создаём группу Bdministrators. В эту группу добавляем нужных пользователей (самого администратора, например). Экспортируем из реестра обе группы по отдельности. Переносим бинарные данные из экспортированного файла от Bdministrators в Administrators, и импортируем его назад. Тем самым, у нас появились правильные администраторы (с правильным id), но неправильным именем. Ну, тут открываем в редакторе реестра бинарный редактор и меняем код байтика, отвечающий за B, на A. Всё, у нас правильные администраторы. Лишнюю группу удаляем, чтобы не мешалась. Повторяем тоже самое для других групп.
Результат — всё красиво и работает.

---

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

Итоги моего года

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

Наверное, в будущем, надо писать в блокнотик, потому что всё уже забылось, а что не забылось — не помню в каком году было...   В общем, из того, что вспомнилось:

С помощью использования своих знаний программиста, я выиграл iPad, научился потрошить приложения на андроиде и хачить их для достижения щастья. Матерился на андроид и перевод времени, позанимался алгоритмическими задачами. Из этих задач, самые интересные: архиватор и поиск разницы в файлах.

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

С поиском разницы в файлах пришлось изобретать велосипед: ибо это не обычный дифф, а дифф файлов, находящихся на разных компьютерах в разных датацентрах. И обмен информации следует максимально сократить. А потом ещё и подумать — искать разницу, или плюнуть и отдать файл целиком. Т.е. в отличии от теории, надо пользоваться жёсткими эвристиками для оценки требуемых действий. И это интересно.

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

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

Торжественно обещаю со следующего года всё доделать и продвинуться ещё дальше, залезть в страшные дебри алгоритмов и наделать мегавещей! И как все остальные обещания начать новую жизнь с понедельника, это также пойдёт лесом. Ну, как всегда  

PS: А ещё я научился собирать кубик Рубика за полторы минуты. А потом разучился. И полностью разучился собирать обычные, дешёвые кубики.

Новогоднее RDP

Скоро новый год, а значит выходные, т.е. к серверам лучше не прикасаться, а если прикасаться, то аккуратно. Естественно, Microsoft всех приучило, что самый простой и ненапряжный способ это сделать - RDP (нет, конечно, PowerShell рулит и бибикает, но назвать этот способ простым, как-то язык не поворачивается).

Итак, RDP живёт, проблем вроде бы нет, но... в один прекрасный момент вы обнаруживаете следующую картину, которые можете наблюдать продолжительное время без видимых результатов.

Другими словами, при попытке подключения — RDP тупит, а потом идёт отлуп с пространными объяснениями, что всё плохо.
Вы дома, сервер далеко, к нему не подойти и не пнуть ногами. Подключиться — не удаётся.
Практика показывает, что это частое явление при разрывах сети. Т.е. кроме разрыва соединения, ещё появляются такие шикарные эффекты. Причем страдают обычно 8-ые винды (т.е. Windows Server 2012 и 2012 R2)
Что в этом случае можно сделать?

Для начала, конечно же выполнить пункт номер 0 — иметь пути отхода и дырку в фаирволле. Причём делать это по-возможности всегда. Т.е. у вас всегда должно быть как минимум 2 пути подключения к серверу (например через рабочий компьютер и через другой сервер), и желательно на определённые IP иметь хороший список открытых портов для этих дружественных компов. Винда это вам не Linux, тут одним SSH не обойдёшься, особенно когда так тупит RDP!

Вариант первый, банальный и неинтересный:

shutdown /m \\server /r /t 1

Отправляем компьютер в ребут... очевидно и неинтересно. Надо идти другими путями. Другие пути заключаются в том, что надо бы перепустить службу Remote Desktop, которая зовётся TermService.

Тут 2 варианта:

sc \\server restart TermService (оцените синтаксис команды относительно предыдущей)

Или же, с помощью мышки: mmc.exe, добавить остнаску, службы, другой компьютер, перезапуск.

Но, тут как всегда нас ждёт сюрприз... в 90% случаях служба зависнет и не захочет останавливаться. Так что придётся добивать её ногами. Битьё усложняется тем, что она висит в процессе svchost.exe (благо обычно на нужном ничего полезного нет).

Так что

tasklist /s server /svc | findstr TermService (оценили синтаксис?)
taskkill /s server /pid 123456

Ну и запускаем службу. Вроде просто и очевидно, но как всегда лезут нюансы: если у нас плохо с логином и паролем (а мы дома, а не в домене), то получим отказ в доступе. Некоторые команды имеют возможность указать логин с паролем, некоторые используют существующее соединение (net use \\server\c$ - получим замечательное подключение и для управления), некоторые просто отказываются работать.

Можно применить PowerShell, создать сессию на сервер и там всё сделать, но ведь его надо настроить... добавить доверие... в общем если вы не занимаетесь этим специально, работать не будет.

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

psexec \\server tasklist /svc

И получить тот же результат (да, мне лень изучать другие команды из этого набора ).

Собственно, зачем я это написал? Вроде очевидные вещи. Да в общем-то с двумя простыми целями: в очередной раз поныть на винду, и показать, что если что-то не работает, можно всё-таки обойтись без перезагрузки.

UPD: Спустя время, надо бы добавить ещё пару команд, которые помогут решить подобную проблему. Ибо у Microsoft всё устроено очень сложно, половина команд может работать, а другая половина не работать с дурацкими сообщениями вида (не шутка):
Couldn't access server:

The operation completed successfully.

Соответственно, tasklist /svc в нашём случае можно заменить на

sc queryex TermService

А вот с taskkill посложнее. Может прокатить скрипт на PowerShell

Invoke-Command -ComputerName server -ScriptBlock {Stop-Process -Id 123456 -Force} -Credential DOMAIN\user