Что значит параметр verbose

Как правильно использовать параметры -verbose и -debug в пользовательском командлете

По умолчанию любая именованная функция, имеющая атрибут [CmdletBinding()], принимает параметры -debug и -verbose (и несколько других) и имеет предопределенные переменные $debug и $verbose . Я пытаюсь выяснить, как передать их другому командлету, который вызывается внутри функции.

Допустим, у меня есть такой командлет:

Если в мою функцию были переданы -debug или -verbose , я хочу передать этот флаг в командлет new-item . Какой правильный шаблон для этого?

ОТВЕТЫ

Ответ 1

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

Один не идеальный, но практически разумный вариант — ввести собственные параметры командлета (например, $MyVerbose и $MyDebug ) и явно использовать их в коде:

UPDATE

Когда нам нужен только переключатель (не скажем, значение уровня многословия), тогда подход с $PSBoundParameters , возможно, лучше, чем предложенный в первой части этого ответа (с дополнительными параметрами):

Всё равно не идеально. Если есть лучшие решения, то я бы очень хотел узнать их сам.

Ответ 2

$PSBoundParameters — это не то, что вы ищете. Использование атрибута [CmdletBinding()] позволяет использовать $PSCmdlet в вашем script, помимо предоставления флага Verbose. На самом деле это то же самое, что вы должны использовать.

Через [CmdletBinding()] вы можете получить доступ к связанным параметрам с помощью $PSCmdlet.MyInvocation.BoundParameters . Здесь функция, которая использует CmdletBinding, и просто сразу вводит вложенное приглашение, чтобы проверить переменные, доступные внутри области функций.

Итак, в вашем примере вам понадобится следующее:

Это охватывает -Verbose, -Verbose: $false, -Verbose: $true и случай, когда переключатель вообще отсутствует.

Ответ 3

Нет необходимости. PowerShell уже делает это, как показано ниже.

Это не делается так же прямо, как передача -Debug для следующего командлета. Это делается через переменные $DebugPreference и $VerbrosePreference. Write-Debug и Write-Verbose действуют так, как вы ожидали, но если вы хотите сделать что-то другое с помощью отладки или подробного описания, вы можете прочитать здесь, как проверить себя.

Ответ 4

Вот мое решение:

Чем это отличается от других примеров, так это тем, что оно будет отображать «-Verbose: $ false» или «-Debug: $ false». Для -Verbose / -Debug будет установлено значение $ true, только если вы используете следующее:

Ответ 5

Вы можете создать новую хеш-таблицу на основе связанных параметров debug или verbose, а затем поместить ее во внутреннюю команду. Если вы просто указываете ключи (и не передаете ложный переключатель, например $debug: $false), вы можете просто проверить наличие отладки или подробного:

Если вы хотите передать значение параметра, это сложнее, но может быть выполнено с помощью

Ответ 6

Лучший способ сделать это — установить $VerbosePreference . Это включит подробный уровень для всего сценария. Не забудьте отключить его в конце скрипта.

Ответ 7

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

Проверка явно для «Продолжить» позволяет script быть равно -verbose:$false при вызове CmdLet из script, который не устанавливает глобальную переменную (в этом случае она $null )

Источник

/VERBOSE (Печать сообщений о ходе выполнения)

Выводит сообщения о ходе выполнения в процессе компоновки.

Синтаксис

Комментарии

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

Параметр	Описание
/VERBOSE	Отображает подробные сведения о процессе компоновки.
/VERBOSE:CLR	Отображает сведения о действиях компоновщика, относящихся к объектам и метаданным, скомпилированным с помощью /clr .
/VERBOSE:ICF	Отображает сведения о действии компоновщика, полученном в результате использования /OPT:ICF .
/VERBOSE:INCR	Отображает сведения о процессе инкрементной компоновки.
/VERBOSE:LIB	Отображает сообщения о ходе выполнения, указывающие только на те библиотеки, в которых выполняется поиск. Отображаемые сведения включают в себя процесс поиска библиотеки. В нем перечислены все библиотеки и имена объектов (с полными путями), символ, который разрешается из библиотеки, и список объектов, ссылающихся на этот символ.
/VERBOSE:REF	Отображает сведения о действии компоновщика, полученном в результате использования /OPT:REF .
/VERBOSE:SAFESEH	Отображает сведения о модулях, несовместимых с защищенной структурной обработкой исключений, если /SAFESEH не указано.
/VERBOSE:UNUSEDDELAYLOAD	Отображает сведения о любых отложенно загруженных библиотеках DLL без символов, используемых при создании изображения.
/VERBOSE:UNUSEDLIBS	Отображает сведения о файлах библиотек, не используемых при создании образа.

Задание данного параметра компоновщика в среде разработки Visual Studio

Откройте диалоговое окно Страницы свойств проекта. Подробнее см. в статье Настройка компилятора C++ и свойства сборки в Visual Studio.

Перейдите на страницу свойствакомандной строки компоновщика свойств конфигурации.

Добавьте параметр в поле Дополнительные параметры .

Источник

Как правильно использовать параметры-verbose и-debug в пользовательском командлете

по умолчанию любая именованная функция с атрибутом [CmdletBinding ()] принимает параметры-debug и-verbose (и несколько других) и имеет предопределенные переменные $debug и $verbose. Я пытаюсь понять, как передать их другим командлетам, которые вызываются внутри функции.

предположим, у меня есть такой командлет:

если -debug или -verbose был передан в мою функцию я хочу передать этот флаг в . Что правильный шаблон для этого?

8 ответов

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

один не идеальный, но практически разумный вариант-ввести свои собственные параметры командлета (например, $MyVerbose , $MyDebug ) и использовать их в коде явно.

обновление

когда мы нужен только переключатель (не, скажем, значение уровня многословия), тогда подход с $PSBoundParameters возможно, лучше, чем предлагаемые выше Дополнительные параметры:

это все не идеально в любом случае. Если есть лучшие решения, то я действительно хотел бы знать их сам.

$PSBoundParameters не то, что вы искали. Использование [CmdletBinding()] атрибут позволяет использовать $PSCmdlet в скрипт, помимо подробного флаг. На самом деле это тот же самый глагол, который вы должны использовать.

через [CmdletBinding()] , вы можете получить доступ к связанным параметров через $PSCmdlet.MyInvocation.BoundParameters . Вот функция, которая использует CmdletBinding и просто вводит вложенное приглашение немедленно, чтобы изучить переменные, доступные внутри функции масштаб.

таким образом, в вашем примере вы хотели бы следующее:

это охватывает-Verbose, — Verbose:$false, — Verbose:$true и случай, когда коммутатор отсутствует вообще.

нет необходимости. PowerShell уже делает это, как показывает приведенный ниже код.

это делается не так прямо, как передача-Debug следующему командлету. Это делается с помощью переменной $а $переменные VerbrosePreference. Write-Debug и Write-Verbose действуют так, как вы ожидали, но если вы хотите сделать что-то другое с debug или verbose, вы можете прочитать здесь как проверить на себе.

С риском оживления и старой нити. Вот мое решение.

чем это отличается от других примеров, так это тем, что он будет повторять «-Verbose:$false» или «-Debug:$false». Он только установит-Verbose/ — Debug в $true, если вы используете следующее:

вы можете создать новую хэш-таблицу на основе связанных параметров debug или verbose, а затем splat ее внутренней команде. Если вы просто указываете переключатели (и не передаете ложный переключатель, например $debug:$false), вы можете просто проверить наличие debug или verbose:

Если вы хотите передать значение параметра, это сложнее, но можно сделать с помощью:

лучший способ сделать это-установить $VerbosePreference . Это позволит включить подробный уровень для всего сценария. Не забудьте отключить его к концу скрипта.

при запуске скрипта можно задать VerbosePreference в качестве глобальной переменной, а затем проверить наличие глобальной переменной в пользовательском командлете.

проверка явно для «продолжить» позволяет сценарию быть равным -verbose:$false при вызове командлета из сценария, который не устанавливает глобальную переменную (в этом случае это $null )

Источник

Ping и некоторые его параметры

«Для чего в команде ping используются опции Loose, Strict, Record, Timestamp и Verbose?» — такой вопрос мне недавно встретился в вендорном экзамене. Они позволяют влиять на маршрутизацию ICMP пакетов и собирать информацию о транзитных L3-устройствах. Но занимаясь сетевыми технологиями уже достаточно давно, я почти никогда их не использовал.

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

Утилита ping нам всем хорошо знакома. Помимо стандартного «ping 8.8.8.8», можно использовать различные опции, среди которых присутствуют интересующие нас. Их наименование и описание у вендоров примерно одинаковое.

• Количество отправляемых пакетов
  Вместо заданного количества пакетов по умолчанию (например, в Windows — четыре, в оборудовании Cisco — пять), мы можем отправить нужное. Сюда же можно отнести многими любимую опцию «-t» в ОС Windows, которая запускает бесконечную отправку пакетов.
• Интерфейс источника
  В первую очередь актуально для сетевого оборудования. По умолчанию, при использовании команды ping устройство отправляет пакет с адресом ближайшего интерфейса к точке назначения. В случае тестирования функций NAT или проверки VPN, возникает необходимость отправлять ICMP пакеты с другого интерфейса. Ещё один классический пример: как доказать коллеге, что у него включён файрвол на хосте, а не сеть глючит. Запускаем ping с ядра сети без указания интерфейса – пингуется. С указанием неближайшего интерфейса – не пингуется.
• Установка DF-бита
  Пакет с установленным DF-битом (=1) не может фрагментироваться. Данную опцию удобно использовать для определения максимально допустимого размера кадра (MTU) между двумя точками. Обычно используется в связке параметрами ниже.
• Размер пакета
  Можно варьировать размер пакета. Вместе с установкой DF-бита помогает в определении MTU. Шлём большой пакет – 1500 байт. Не проходит. Шлём чуть меньше – 1300. Проходит. Шлём 1400. И так далее. В общем, метод дихотомии и MTU определён.
  В Windows мы указываем размер сегмента данных ICMP пакета. На устройствах Cisco – размер пакета IP с учётом заголовков.
• Вариация размера пакета в указанном диапазоне
  Для тех, кто не любит метод дихотомии, может пригодиться данный режим. Мы указываем начальное значение размера пакета, конечное и шаг. Далее устройство отправляет пакеты, постепенно увеличивая их размер. Главное не забыть выставить DF-бит, а то всё насмарку.

За бортом остался ряд других опций (timeout, ToS и пр.), которыми лично я практически не пользуюсь.

Опции Loose, Strict, Record, Timestamp, Verbose включены в утилиту ping на многих сетевых устройствах. Есть поддержка в Windows.

Record (Record Route)

Пакет ICMP с опцией Record при прохождении через L3-устройства записывает IP-адреса исходящих интерфейсов. Делается это как в сторону пункта назначения, так и обратно. Это удобно, например, при диагностировании проблем, связанных с асинхронной маршрутизацией. Получается вроде traceroute, только лучше.

Но рано радоваться: максимальное количество записей равно девяти. Причём в них входят данные об IP-адресах устройств в обе стороны. Обусловлено данное ограничением тем, что информация об IP-адресах сохраняется не в теле пакета, а в заголовке. Поле с опциями не может быть слишком большим. Оно ограничено 40 байтами. Нам, в конце концов, по сети нужно гонять полезные данные, а не заголовки. В этот объём помещается всего девять записей (4 байт на каждый IPv4 адрес). Оставшиеся (40-4*9)=4 байта уходят на отметку о типе опции, длине и пр. атрибутах. Напомню, максимальный размер всего заголовка IPv4 – 60 байт.

Запускаем с ПК под управлением ОС Windows ping с опцией Record Route (-r) до адреса 192.168.36.2:

Пакeт ICMP Echo Request c выставленной опцией Record Route (Type = 7) в заголовке IP:

ICMP Echo Request доходит до получателя. По пути в него добавляются адреса транзитных устройств. Получатель берёт заполненные поля опции IP заголовка, копирует их в ICMP Echo Reply и отправляет назад. Пока ICMP Echo reply доберётся до инициатора пинга, он обрастёт записями обратного маршрута.

В ответном пакете ICMP Echo Reply, который получит ПК, опция Record Route будет уже заполнена:

Можно заметить, что в нашей сети имеет место ассиметричная маршрутизация.

Когда пакет ICMP с опцией Timestamp проходит через L3-устройство, оно записывает в него метку с указанием текущего времени. Схема работы аналогична опции Record, только вместо адреса ставится время. Как и в предыдущем случае пакет может содержать только девять записей о времени (для ОС Windows – четыре, так как кроме временной метки, добавляется IP-адрес устройства).

Время в пакете указано в формате UNIX time. Анализ данных имеет хоть какой-то смысл, если все устройства синхронизированы по времени (в нашем примере этого нет).

Strict (Strict Source Route)

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

Работает опция просто: на каждом хопе IP-адрес назначения меняется на тот адрес, который мы указали при запуске утилиты ping.

Все адреса хранятся в заголовке IP нашего ICMP пакета. Поэтому каждое транзитное устройство может их подсмотреть. Такая схема позволяет обходить текущие правила маршрутизации на каждом устройстве, так как фактически имеем пересылку пакета на соседнее устройство.

В нашей схеме R2 имеет маршрут в сеть 192.168.36.0/24 через R3. Но так как у нас жёстко прописаны устройства в опциях ICMP пакета, R2 передаст его напрямую на R4.

Запускаем утилиту ping с опцией -k (Strict Source Route) в ОС Windows и прописываем адреса устройств.

Пакeт ICMP Echo Request c выставленной опцией Strict Source Route (Type = 137) в заголовке IP на нашем ПК выглядит следующим образом:

ПК подставил 192.168.20.1 в качестве адреса получателя. Остальные адреса транзитных устройств благополучно запаковал в поля опции IP (записи Source Route). Адрес конечного устройства добавил в запись Destination.

Этот же пакет, после того, как он минует R1:

IP-адрес отправителя остался без изменений. IP-адрес получателя поменялся на новый – 192.168.31.1. Это значение взято из поля Source Route, когда пакет ICMP только поступил на R1.

Важно отметить, что R1 занёс в поле опций новую запись — Recorded Route. Туда подставлен IP-адрес интерфейса R1. Данное поле понадобится, чтобы ответный пакет (ICMP Echo reply) вернулся по тому же маршруту, что и ICMP Echo request. Точно также будут поступать и остальные устройства. Поэтому, когда пакет ICMP попадёт на R5, в опции Strict Source Route будет содержаться список IP-адресов интересов, через которые должен пройти ответный пакет.

ICMP Echo reply, полученный ПК:

Поле Recorded Route переписывается по мере прохождения пакета ICMP Echo reply, так как там всегда указан адрес исходящего интерфейса для текущего пакета. Поэтому R1, когда получит ICMP Echo reply, заменит 192.168.31.2 на 192.168.20.1.

Если в команде ping мы опустим один из адресов, например, последний (192.168.35.1 – R5), R4 должен будет отправить пакет сразу на устройство с адресом 192.168.36.2. Но так как эта сеть не является для него локальной, R4 отрапортует о том, что заданный узел недостижим. Маршрутизировать пакет по обычным правилам он не будет.

Для обработки опции Record на сетевом оборудовании должен быть включен режим source routing. Например, на оборудовании Cisco он включён по умолчанию.

Loose (Loose Source Route)

Данная опция по сути очень похожа на опцию Strict. Но, в отличии от Strict, в опции Loose задаётся не жёсткий маршрут движения ICMP пакета, а лишь выборочные устройства. Т.е. пакет может маршрутизироваться и другими устройствами. Максимальное количество адресов – девять.

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

Запускаем утилиту ping с опцией -j (Loose Source Route) в ОС Windows и прописываем адреса устройств.

Пакeт ICMP Echo Request c выставленной опцией Loose Source Route (Type = 131) в заголовке IP на нашем ПК выглядит так:

ПК подставил адрес R3 (192.168.32.1) в качестве получателя. При этом адрес конечного устройства R5 (192.168.36.2) указал в опции IP (запись Destination). Далее пакет маршрутизируется в сети по обычным правилам, пока не попадёт на R3. R3 подставит в качестве адреса назначения адрес R5 и в опциях пропишет свой адрес, через который должен будет вернуться ответный пакет (запись Recorded Route). После чего отправит его в сеть.

Ответный пакет ICMP Echo reply особого интереса не представляет, так как аналогичен ранее рассмотренным. В опциях будет указан адрес исходящего интерфейса R3 (запись Recorded Route), через который прошел пакет.

Данная опция активируется автоматически при выборе любой из ранее описанных. Предоставляет более детальный вывод информации на экран. На сам пакет ICMP она никак не влияет. В Windows в команде ping такой опции нет.

Чтобы мы могли воспользоваться этими опциями, промежуточное оборудование должно их поддерживать. С этим проблем не будет. К новшествам мира ИТ относить весь этот «rocket science» не приходится. Напрашивается вывод: опции Loose, Strict, Record, Timestamp могут быть полезны, даже с учётом ограничения в «девять». Если бы не следующие нюансы, связанные с безопасностью.

Первое. Опции Record и Timestamp могут благополучно использоваться для проведения разведки в сети. С их помощью можно исследовать топологию сети, получить отпечатки, по которым определить ОС и тип устройства, через которые проходил пакет с данными опциями.

Второе. Опции Loose и Strict позволяют управлять движением пакета, игнорируя стандартные правила маршрутизации. Это предоставляет широкие возможности для попыток проникновения в различные сегменты сети, куда в случае обычной маршрутизации доступа не должно быть. Также возможно проведение разведки для анализа топологии сети. Проведение атак по утилизированию полосы пропускания на определённых сегментах сети. Вариантов много.

Третье. Часть сетевого оборудования обрабатывает пакеты с установленными опциями программным образом на уровне control-plane (без использования различных схем оптимизации маршрутизации трафика), что безусловно нагружает ЦПУ. А значит есть возможность осуществить DoS атаку на такое устройство.

Многие вендоры (есть даже отдельное RFC 7126) рекомендуют пакеты с указанными опциями никак не обрабатывать. Варианты предлагают разные. Вплоть до отбрасывания таких пакетов. Правда у некоторых из производителей бывают диссонансы: с одной стороны рекомендуем отбрасывать такие пакеты, с другой — «Record is a very useful option».

Быстрая попытка проверить соответствие этим рекомендациям у пары интернет-провайдеров показали, что часть опций всё-таки работает. Но source routing отключён везде.

Получается интересный вывод. Опции Loose, Strict, Timestamp, Record могут быть полезны при диагностике проблем в сети. Но вопрос безопасности нивелирует это.

В итоге у меня всё-таки осталось чувство непонимания. Почему озвученный в начале вопрос присутствовал в тесте? Относительно полезна опция Record и то при небольшой глубине сети. Остальные опции под вопросом.

Напоследок небольшой опрос. Всем хорошего дня!

Источник