Надеюсь этот подход показался вам интересным, пишите что вы об этом думаете, коллеги и друзья!
Думаю, что в случае использования платформ от Microsoft (Windows Server, Azure, .Net, ODBC/OLE DB/ADO.Net совместимые поставщики данных, которые есть и для сторонних баз данных) есть хороший шанс обойтись без изобретения своего велосипеда — самописного координатора распределенных транзакций.
А вместо этого использовать классы из System.Transactions, с которыми многие такие поставщики интегрируются как менеджеры транзакций (в терминологии System.Transactions)
А если не интегрируются «из коробки», то можно попробовать обойтись малой кровью — реализацией своего менеджера транзакций для источника, как написано в документации. Насколько мне известно, этот механизм остался во всех последующих версиях .Net Framework.
А также — перенесен в актуальные версии .Net Core — по крайней мере, при беглом взгляде на документацию по нему нужные классы, интерфейсы и методы, вроде как, есть. Но сам я ничего в этой области не писал, так что как в реальности там обстоят дела, утверждать с уверенностью не могу.
Именно. Причем, если так — в скобках через запятую — захотеть передать два аргумента, то внезапно будет передан один — массив из двух элементов.
PS А вот к вызовам методов объектов это не относится — методы вызываются именно со списком аргументов в скобках через запятую.
Не получается, потому что Linq построен на методах раширения (extention method), позволяющих вызывать в качестве методов экземпляров класса методы, специальным образом определеные в другом классе. А в Powershell этот механизм не реализован. В нем соответсвующие методы нужно вызывать явно, через тот класс, в котором они реально определены.
В Powershell для реализации аналогичной функциональности используется другой механизм, свойственный как раз shell-языкам: конвейер и команды (commandlet), которые принимают коллекции по конвейеру на вход, обрабатывают их элементы (или даже коллекцию целиком, например — сортируют ее) определенным образом и передают результат по конвейеру на выход. Скрипты, если они написаны определенным образом, тоже умеют так работать, в качестве таких команд-фильтров.
Кстати, у Powershell есть в этом отношениии еще одна особенность. На выходе из конвейера наружу результаты выглядят как массив, если их несколько, или как одиночный элемент, если элемент один. Такое поведение удобно для интерактивной работы, но вот написание скриптов, наоборот, затрудняет.
Посмотрел кратко ваши публикации и не увидел, чтобы вы рассматривали хоть один язык командной оболочки (shell). Из чего заключаю, что вы просто оцениваете Powershell не в том контексте применения, для которого он предназначен.
Так вот, для языка комнадной оболочки написание программ (скриптов) — это только одна область примения, и не факт, что самая важная. Другая очень важная область применения такого языка — выдача интерактивных команд, причем часто — не одиночных команд, а их связок: взять выдачу одной команды, передать на вход другой для преобразования и т.д. Причем, часто бывает желательным, чтобы вся связка умещалась на одной строке — чтобы было проще вернуть её из истории (стрелкой вверх, например) и выполнить заново.
Лично мне, например, как системному администратору MS Exchange по основному роду занятий, такие вещи приходится проделывать очень часто.
Поэтому сложные конструкции из нескольких команд — типа набора операторов присваивания, операторов цикла — для интерактивной работы подходят плохо. А в языках командной оболочки для этой цели есть очень удобное средство — конвейер (pipe).
Есть и другие особенности Powershell — как свойственные многим другим языкам командной оболочки, так и уникальные именно для него — которые облегчают именно интерактивное выпонение команд. Надеюсь, авторы этой серии о них расскажут.
Ну, по 272 их вряд ли привлечь можно. Потому как под неправомерным доступом к информции закон подразумевает «проникновение в ее источник с использованием средств (вещественных и интеллектуальных) компьютерной техники, позволяющее использовать полученную информацию (копировать, модифицировать, блокировать либо уничтожать ее)» (см. «Методические рекомендации по осуществлению прокурорского надзора за исполнением законов при расследовании преступлений в сфере компьютерной информации»). Здесь же сам источник информации — сайт — остается в неприкосновенности.
А вот что, на мой взгляд, более перспективно по отношению к таким деятелям — использовать против них механизм охраны аворского права, потому как тут налицо явное искажение произведения, каковым является содержимое сайта. Или — распространение своего произведения сделанного на основе защищаемого без согласия его автора.
PS Но, вообще-то, юрист я не настоящий, так что запросто мог ошибиться.
Как я понял, в реальности эта новость означает несколько другое: команда разработки Exchange наконец-то удосужилась провести тестирование и доработку для предназначенных для работы на земле Exch2013-19 (Exch2010 ниасилили), чтобы им гарантированно не требовался SMB1.
А так, больше ничего нового: стремление нынешней MS избавиться от поддержки совместимости со старыми системами (вместо того, чтобы исправлять ошибки в реализации старых протоколов)- оно давно и хорошо известно.
Благодарю за то, что поделились реальной историей из реальной жизни. Потому как стандарные «истории успеха» читать тут уже поднадоело.
PS А HPE (которая раньше была известна как просто HP) мне всегда не нравилась своими шибко хитрыми подходами: использованием несовместимой со стандарной комплектухой начинкой серверов, постоянной увязко обновления прошивок с обновлениями драйверов и т.п. привычками поставщиков двора Его величества AKA «enterprise level».
Потому я всегда был сторонником закупки вместо пары серверов HP 3-4 серверов локальных сборщиков за те же деньги, одному из коих было предназначено быть в теплом резерве (с использованием его в качестве «песочницы» для поиграться и т.п.).
Помнится, лет десять и чуть более назад IPMI (который умеет примерно то же самое) был практически на всех платах Supermicro, которые тогда активно использовались самосборщиками и приравненными к ним местными производителями (особенно мне памятен Kraftway — например, благодаря его замечательному RAID-контроллеру я имел возможность вживую полюбоваться на USN rollback в AD и даже потренироваться в его устранении).
Но с тех пор самосбором и прочими крафтвяеми я дела как-то не имел Что, с тех пор хуже стало?
Ну, это не факт, что сделали бы лекарство. Общеизвестно, например, что японцы во время Второй Мировой разрабатывали бактериологическте оружие на основе возбудителей болезней, средствами лечения которых они не обладали.
Но в обсуждаем контексте это даже не важно. Тут важен факт невозможности доказать, что эпидемия в Ухани не была вызвана утечкой уже изученного вируса из местной биолаборатории. А потому ставить быстрое получение инфорации о возбудителе в заслугу именно информационным технологиям нельзя: для этого может быть совсем другая причина. А может — и не быть: в силу закрытости Китая правду мы при своей жизни вряд ли узнаем.
Так что я бы данный случай просто вообще бы в статье не упоминал — в силу его неоднозначности.
Например, справляться со злободневным коронавирусом 2019-nCoV помогает оперативность предоставляемой Китаем информации о случаях заболеваний и результатах исследований, которая не в последнюю очередь стала возможной благодаря современным информационным технологиям, в том числе облачным. Сравните: для подтверждения эпидемии (а значит, получения и анализа данных о состоянии здоровья людей, изучения вируса в течение какого-то времени) атипичной пневмонии, вызванной коронавирусом SARS, Китаю в 2002 году потребовалось около восьми месяцев! В этот раз официальная информация была получена Всемирной организацией здравоохранения моментально – через семь дней.
А может быть, есть какая-то другая причина, с IT вообще и облачными технологиями никак не связанная, по котоой в этот раз китайские власти обладают значительно более полной информацией, чем во время эпидемии SARS — вы такой вариант не рассматривали? Например, что если SARS был действительно вызван «диким» вирусом, который потребовалось выделить и доказать, что он являлся причиной атипичной пневмонии (на что, естествено, ушла куча времени), а вирус Уханьской пневмонии был разработан в Уханьском институте вирусологии (где находится единственная в Китае лаборатория с наивысшим уровнем биологической защиты) и по случайности вырвался за пределы лаборатории — а потому вся информация о вирусе уже имелась в наличии, и единственное, что требовалось — это политическое решение о том, чтобы эту информацию не скрывать? А продемонстрированный уровень оперативности, при условии принятия правильного политического решения, вполне достигался и «IT-технологиями» столетней данвости — почтой, перевозимой железной дорогой, например?
То есть дело — ну совсем не в облаках?
С разумными рекомендациями не надо бороться. Надо им следовать.
Полностью согласен. Но — при условии, что рекомендация действительно разумная.
Разумность же обсуждаемой рекомендации зависит от условий предприятия, где она используется — я про это написал выше.
Вас не смущает, что по сети летает в открытом виде информация из AD? И что логин пароль можно соснифферить влёгкую?
Если в AD не хранятся персональные данные, и для доступа сторонних сервисов к AD (которым обычно нужен доступ только на чтение общедоступной информации) используются учетные данные обычного пользователя — то не смущают: как правило, у потенциального атакующего эквивалентные данные уже есть. Если, конечно, у предприятия нет особых требований к сетевой безопасности.
Не вижу тут никакого влияния здравого смысла. По крайней мере — никакого нового, связанного с патчем.
Если ваш здравый смысл — к примеру, здравый смысл админа сети банка, которому требуется проходить аудиты безопасности и у которого вообще по жизни в этой сети реальное бабло есть — требует использовать эти меры безопасности, то эти меры уже должны быть реализованы, сразу, не дожидаясь изменения настроек по умолчанию.
А, к примеру, здравому смыслу админу конторка «купи-продай», сеть которой не заслуживает внимания атакующих, весь этот лишний геморрой, наоборот никак не требуется.
Не хватает важного уточнения, что теперь PKI становится необходимой для всех, кто обращается по LDAP к каталогу.
Ни в коем случае. Меняется всего лишь поведение по умолчанию, которое можно переопределить. Microsoft, конечно, не хочет обращать на это внимание — и в результате появляется совершенно невнятная рекомендация по безопасности ADV190023 — но возможность отказаться от этой, типа, заботы о нас (заботы типа «помог перейти старушке через улицу, хотя этой ей туда совсем не надо было») таки существует: достаточно внимательно прочитать статьи MS KB по ссылкам в рекомендации — 1 и 2 а также статью из блога, касающуюся этого обновления
Для этого нужно установить два значения типа DWORD в реестре (привожу для AD DS, для AD LDS нужно вместо NTDS подставить имя экземпляра):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding=0 — чтобы отключить требование Channel Binding
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity=0 — чтобы отключить требование LDAP Signing
Если этих значений нет — надо их создать. Второе значение для AD DS контролируется ещё и групповой политикой Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain controller: LDAP server signing requirements, и сейчас там (по крайней мере — в свежем домене на Win2012 R2) по умолчанию в Default Domain Controller Policy стоит отключение требования, что выливается в значение ключа =1, из-за чего после обновления требование LDAP Signing реально будет применяться. Однако, согласно статье в блоге, установка указанного параметра в 0 приведет к тому, что этого после обновления требования LDAP Signing не будет. Как это будет реализовано — я таки не понял. Потому думаю, что на всякий случай, этот параметр политики надо поставить в положение Отключено а нужное (=0) значение — установить напрямую в реестре на всех КД.
Думаю однако, что после появления обновления всё это надо будет, на всякий случай, протестировать на стенде.
Ну, я код ваш не отлаживал, потому за причину ошибки точно сказать не могу.
Но мне сразу бросилось в глаза некорректное сравнение в последнем if-then-else:
if (node.next > 0) {
0 — это вполне допустимое значение для ссылки на следующий элемент в цепочке, а код написан так, как будто 0 — пустое значение. Каковы последствия этой ошибки — я не анализировал, потому сказать, та ли это ошибка была или нет (и не было ли других), я не могу.
Естественно, использование явной проверки на непустое значение с помощью типчиков исправило эту ошибку. Но букв для этого вам написать пришлось заметно больше, не правда ли?
PS Однако экономия 2-х дней и потраченных за это время нервов лично для вас очевидно была целесообразной, не спорю.
Вы задали очень неоднозначный вопрос, поэтому требуются пояснения.
В каком именно DevOps, на базе какой платформы? Linux? Windows? Какого-нибудь PaaS вроде Azure или AWS?
И что вы понимаете под словом «знание» (см. мой ответ выше)?
Вы тут почему-то на совсем другую тему скатились.
Изначально-то вы заявляли другое:
Знания Виндоус и наземной инфраструктуры Майкрософт бесполезны для переката в девопс
То есть речь шла о знаниях о Windows. А не о том, насколько они востребованы в данной конкретной области в данный конкретный момент и в данной конкретной стране.
Или вы под «знаниями» имеете в виду ценные сведения, где именно находятся галочки в GUI или как пишутся ключи команд в CLI, без понимания того, как оно все работает — то есть без знания соответствущих технологий? Ну, тогда да: знание галочек ничем не поможет нахождению нужных ключей. Можете утешиться — таким Win-админам в DevOps перейти будет очень сложно. Но для них есть другая работа, по их квалификации и за, соответственно, меньшие деньги. И этой работы сейчас много. И облака им мало чем угрожают: к примеру, окошки и галочки в том же Exchange Online — они вполне похожи на те, что в Exchange.
Однако в системном администрировании есть другой слой знаний — знание технологий. Вот он поможет сменить платформу — потому как технологии на разных платформах используются довольно сходные.
Думаю, что в случае использования платформ от Microsoft (Windows Server, Azure, .Net, ODBC/OLE DB/ADO.Net совместимые поставщики данных, которые есть и для сторонних баз данных) есть хороший шанс обойтись без изобретения своего велосипеда — самописного координатора распределенных транзакций.
А вместо этого использовать классы из System.Transactions, с которыми многие такие поставщики интегрируются как менеджеры транзакций (в терминологии System.Transactions)
А если не интегрируются «из коробки», то можно попробовать обойтись малой кровью — реализацией своего менеджера транзакций для источника, как написано в документации. Насколько мне известно, этот механизм остался во всех последующих версиях .Net Framework.
А также — перенесен в актуальные версии .Net Core — по крайней мере, при беглом взгляде на документацию по нему нужные классы, интерфейсы и методы, вроде как, есть. Но сам я ничего в этой области не писал, так что как в реальности там обстоят дела, утверждать с уверенностью не могу.
Идея в том, что завершение транзакции разбивается на две фазы. Все (ну, в реальности — почти все, потому как «стопроцентную гарантию дает только страховой полис»© ) операции, которые могут вызвать отказ фиксации, выполняются в первой фазе транзакции. А во второй фазе выполняются только операции, отказ при которых «невозможен»: транзакция помечается как завершенная, освобождаются все связанные с ней ресурсы (блокировки, в частности) и т.п.
Соответственно, координатор транзакций — само приложение или специально обученная программа типа MS DTC — сначала выполняет первую фазу у всех участников (в терминологии MS DTC или System.Transactions — менеджеров транзакций), а потом — вторую фазу у них же.
А вот, что происходит, если между первой и второй перерывчик подзатянулся (например, один из менеджеров транзакций упал) — за это я не скажу, потому что программист я не настоящий, а это надо в конкретную документацию по конкретному координатору лезть.
PS Ну, а теорию все наверное помнят: что в распределенной системе с ненадежным каналом связи между частями невозможно гарантировать, что все части находятся в согласованном состоянии. Так что, если в принципе, то место для ошибки найдется при любой схеме координации транзакций. И речь идет лишь о том, чтобы снизить вероятность ошибки.
PS А вот к вызовам методов объектов это не относится — методы вызываются именно со списком аргументов в скобках через запятую.
В Powershell для реализации аналогичной функциональности используется другой механизм, свойственный как раз shell-языкам: конвейер и команды (commandlet), которые принимают коллекции по конвейеру на вход, обрабатывают их элементы (или даже коллекцию целиком, например — сортируют ее) определенным образом и передают результат по конвейеру на выход. Скрипты, если они написаны определенным образом, тоже умеют так работать, в качестве таких команд-фильтров.
Кстати, у Powershell есть в этом отношениии еще одна особенность. На выходе из конвейера наружу результаты выглядят как массив, если их несколько, или как одиночный элемент, если элемент один. Такое поведение удобно для интерактивной работы, но вот написание скриптов, наоборот, затрудняет.
Так вот, для языка комнадной оболочки написание программ (скриптов) — это только одна область примения, и не факт, что самая важная. Другая очень важная область применения такого языка — выдача интерактивных команд, причем часто — не одиночных команд, а их связок: взять выдачу одной команды, передать на вход другой для преобразования и т.д. Причем, часто бывает желательным, чтобы вся связка умещалась на одной строке — чтобы было проще вернуть её из истории (стрелкой вверх, например) и выполнить заново.
Лично мне, например, как системному администратору MS Exchange по основному роду занятий, такие вещи приходится проделывать очень часто.
Поэтому сложные конструкции из нескольких команд — типа набора операторов присваивания, операторов цикла — для интерактивной работы подходят плохо. А в языках командной оболочки для этой цели есть очень удобное средство — конвейер (pipe).
Есть и другие особенности Powershell — как свойственные многим другим языкам командной оболочки, так и уникальные именно для него — которые облегчают именно интерактивное выпонение команд. Надеюсь, авторы этой серии о них расскажут.
А вот что, на мой взгляд, более перспективно по отношению к таким деятелям — использовать против них механизм охраны аворского права, потому как тут налицо явное искажение произведения, каковым является содержимое сайта. Или — распространение своего произведения сделанного на основе защищаемого без согласия его автора.
PS Но, вообще-то, юрист я не настоящий, так что запросто мог ошибиться.
А так, больше ничего нового: стремление нынешней MS избавиться от поддержки совместимости со старыми системами (вместо того, чтобы исправлять ошибки в реализации старых протоколов)- оно давно и хорошо известно.
PS А HPE (которая раньше была известна как просто HP) мне всегда не нравилась своими шибко хитрыми подходами: использованием несовместимой со стандарной комплектухой начинкой серверов, постоянной увязко обновления прошивок с обновлениями драйверов и т.п. привычками поставщиков двора Его величества AKA «enterprise level».
Потому я всегда был сторонником закупки вместо пары серверов HP 3-4 серверов локальных сборщиков за те же деньги, одному из коих было предназначено быть в теплом резерве (с использованием его в качестве «песочницы» для поиграться и т.п.).
Но с тех пор самосбором и прочими крафтвяеми я дела как-то не имел Что, с тех пор хуже стало?
Но в обсуждаем контексте это даже не важно. Тут важен факт невозможности доказать, что эпидемия в Ухани не была вызвана утечкой уже изученного вируса из местной биолаборатории. А потому ставить быстрое получение инфорации о возбудителе в заслугу именно информационным технологиям нельзя: для этого может быть совсем другая причина. А может — и не быть: в силу закрытости Китая правду мы при своей жизни вряд ли узнаем.
Так что я бы данный случай просто вообще бы в статье не упоминал — в силу его неоднозначности.
А может быть, есть какая-то другая причина, с IT вообще и облачными технологиями никак не связанная, по котоой в этот раз китайские власти обладают значительно более полной информацией, чем во время эпидемии SARS — вы такой вариант не рассматривали? Например, что если SARS был действительно вызван «диким» вирусом, который потребовалось выделить и доказать, что он являлся причиной атипичной пневмонии (на что, естествено, ушла куча времени), а вирус Уханьской пневмонии был разработан в Уханьском институте вирусологии (где находится единственная в Китае лаборатория с наивысшим уровнем биологической защиты) и по случайности вырвался за пределы лаборатории — а потому вся информация о вирусе уже имелась в наличии, и единственное, что требовалось — это политическое решение о том, чтобы эту информацию не скрывать? А продемонстрированный уровень оперативности, при условии принятия правильного политического решения, вполне достигался и «IT-технологиями» столетней данвости — почтой, перевозимой железной дорогой, например?
То есть дело — ну совсем не в облаках?
Полностью согласен. Но — при условии, что рекомендация действительно разумная.
Разумность же обсуждаемой рекомендации зависит от условий предприятия, где она используется — я про это написал выше.
Если в AD не хранятся персональные данные, и для доступа сторонних сервисов к AD (которым обычно нужен доступ только на чтение общедоступной информации) используются учетные данные обычного пользователя — то не смущают: как правило, у потенциального атакующего эквивалентные данные уже есть. Если, конечно, у предприятия нет особых требований к сетевой безопасности.
Если ваш здравый смысл — к примеру, здравый смысл админа сети банка, которому требуется проходить аудиты безопасности и у которого вообще по жизни в этой сети реальное бабло есть — требует использовать эти меры безопасности, то эти меры уже должны быть реализованы, сразу, не дожидаясь изменения настроек по умолчанию.
А, к примеру, здравому смыслу админу конторка «купи-продай», сеть которой не заслуживает внимания атакующих, весь этот лишний геморрой, наоборот никак не требуется.
Но надо будет окончательно протестировать.
Ни в коем случае. Меняется всего лишь поведение по умолчанию, которое можно переопределить. Microsoft, конечно, не хочет обращать на это внимание — и в результате появляется совершенно невнятная рекомендация по безопасности ADV190023 — но возможность отказаться от этой, типа, заботы о нас (заботы типа «помог перейти старушке через улицу, хотя этой ей туда совсем не надо было») таки существует: достаточно внимательно прочитать статьи MS KB по ссылкам в рекомендации — 1 и 2 а также статью из блога, касающуюся этого обновления
Для этого нужно установить два значения типа DWORD в реестре (привожу для AD DS, для AD LDS нужно вместо NTDS подставить имя экземпляра):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding=0 — чтобы отключить требование Channel Binding
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity=0 — чтобы отключить требование LDAP Signing
Если этих значений нет — надо их создать. Второе значение для AD DS контролируется ещё и групповой политикой Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain controller: LDAP server signing requirements, и сейчас там (по крайней мере — в свежем домене на Win2012 R2) по умолчанию в Default Domain Controller Policy стоит отключение требования, что выливается в значение ключа =1, из-за чего после обновления требование LDAP Signing реально будет применяться. Однако, согласно статье в блоге, установка указанного параметра в 0 приведет к тому, что этого после обновления требования LDAP Signing не будет. Как это будет реализовано — я таки не понял. Потому думаю, что на всякий случай, этот параметр политики надо поставить в положение Отключено а нужное (=0) значение — установить напрямую в реестре на всех КД.
Думаю однако, что после появления обновления всё это надо будет, на всякий случай, протестировать на стенде.
Но мне сразу бросилось в глаза некорректное сравнение в последнем if-then-else:
if (node.next > 0) {
0 — это вполне допустимое значение для ссылки на следующий элемент в цепочке, а код написан так, как будто 0 — пустое значение. Каковы последствия этой ошибки — я не анализировал, потому сказать, та ли это ошибка была или нет (и не было ли других), я не могу.
Естественно, использование явной проверки на непустое значение с помощью типчиков исправило эту ошибку. Но букв для этого вам написать пришлось заметно больше, не правда ли?
PS Однако экономия 2-х дней и потраченных за это время нервов лично для вас очевидно была целесообразной, не спорю.
Вы задали совершенно неоднозначный вопрос, и поэтому я прошу вас дополнительно его пояснить. Что вам тут кажется неправильным?
В каком именно DevOps, на базе какой платформы? Linux? Windows? Какого-нибудь PaaS вроде Azure или AWS?
И что вы понимаете под словом «знание» (см. мой ответ выше)?
Изначально-то вы заявляли другое:
То есть речь шла о знаниях о Windows. А не о том, насколько они востребованы в данной конкретной области в данный конкретный момент и в данной конкретной стране.
Или вы под «знаниями» имеете в виду ценные сведения, где именно находятся галочки в GUI или как пишутся ключи команд в CLI, без понимания того, как оно все работает — то есть без знания соответствущих технологий? Ну, тогда да: знание галочек ничем не поможет нахождению нужных ключей. Можете утешиться — таким Win-админам в DevOps перейти будет очень сложно. Но для них есть другая работа, по их квалификации и за, соответственно, меньшие деньги. И этой работы сейчас много. И облака им мало чем угрожают: к примеру, окошки и галочки в том же Exchange Online — они вполне похожи на те, что в Exchange.
Однако в системном администрировании есть другой слой знаний — знание технологий. Вот он поможет сменить платформу — потому как технологии на разных платформах используются довольно сходные.