По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Новый менеджер пакетов Windows от Microsoft упрощает установку приложений, позволяя это делать одной командой. В этой статье рассказываем про Windows Package Manager и новую команду winget.
Что такое менеджер пакетов Windows?
Менеджеры пакетов распространены в Linux. Вместо того, чтобы искать приложение в Интернете, загрузить установщик и запускать мастер установки, вы можете просто запустить быструю команду для поиска и установки приложения по его имени.
Например, чтобы установить Microsoft PowerToys, вы можете открыть окно терминала и ввести winget install powertoys. Команда автоматически найдет, загрузит и установит программное обеспечение без каких-либо дополнительных действий с вашей стороны. Это так просто.
Под капотом Microsoft размещает собственный репозиторий программного обеспечения, а другие организации и частные лица могут размещать свои собственные репозитории. Это важная функция, которая повышает производительность в Linux, особенно для разработчиков и системных администраторов.
Менеджер пакетов Windows - это проект с открытым исходным кодом, доступный и на GitHub.
Как установить менеджер пакетов Windows
Начиная с 19 мая 2020 года менеджер пакетов Windows доступен в форме предварительного просмотра. Позднее он будет интегрирован непосредственно в обновление для Windows 10.
Сейчас есть несколько способов получить его:
Установите инсайдерскую сборку Windows 10, зарегистрируйтесь в программе инсайдеров Windows Package Manager и установите обновление для пакета установщика приложений из Магазина Microsoft. Вы получите автоматические обновления диспетчера пакетов Windows по мере их выпуска, но вам придется запустить нестабильную версию Windows 10.
Загрузите менеджер пакетов Windows .appxbundle с GitHub. Установите его, дважды щелкнув файл и нажав Update. Вы должны будете установить будущие обновления вручную с этой же страницы загрузки, но вам не придется запускать нестабильную версию Windows 10.
В будущем в этом нет необходимости, и winget будет встроен во все стабильные версии Windows 10. По состоянию на май 2020 года он находится в форме предварительного просмотра, так как Microsoft тестирует его и устраняет ошибки.
Как использовать winget, менеджер пакетов Windows
Вы можете запустить winget из Windows PowerShell или из классической командной строки. Мы рекомендуем установить новый терминал Windows, если вы этого еще не сделали.
Вы можете скачать Windows Terminal из Магазина Microsoft. Вы даже можете получить исходный код на GitHub. Да, новый терминал Windows с открытым исходным кодом.
Из командной строки выполните команду winget, чтобы просмотреть дополнительную информацию об использовании инструмента.
Чтобы найти приложение, выполните следующую команду, заменив name поисковой фразой:
winget search name
Чтобы установить приложение, выполните следующую команду, заменив name на имя приложения:
winget install name
Для просмотра дополнительной информации о приложении выполните следующую команду, заменив name именем приложения или поисковой фразой:
winget show name
Чтобы просмотреть полный список доступных приложений, выполните следующую команду:
winget install
В своем первоначальном выпуске репозитории winget уже заполнены широким спектром популярных настольных приложений. Вы найдете все, от обычных приложений для настольных систем Windows до инструментов для разработчиков. Список включает в себя Google Chrome, Mozilla Firefox, Zoom, Steam, медиаплеер VLC, Spotify, терминал Windows, код Visual Studio, Ruby, Microsoft PowerToys и многие другие.
Чтобы управлять источниками, запустите winget source. Вы увидите список команд. Например, чтобы просмотреть текущие источники, запустите:
winget source list
В первоначальной версии winget есть только встроенный исходный код winget, управляемый Microsoft, расположенный по адресу https://winget.azureedge.net/cache. В будущем вы сможете добавлять сторонние источники с помощью дополнения winget source.
Вы можете увидеть больше информации о том, как использовать одну из встроенных команд winget, добавив -? к нему. Например, чтобы увидеть различные опции, которые вы можете использовать с winget, выполните следующую команду:
winget search -?
Заключение
Теперь вы знаете как работать с менеджером пакетов winget. Microsoft наверняка добавит дополнительные функции в диспетчер пакетов Windows в будущем, и он станет только более мощным. А другие статьи про Windows можно прочитать в нашем разделе.
В одной из предыдущих статей мы рассматривали межсетевой экран ASA и порядок его первоначальной настройки. Но ничего не стоит на месте и в какой-то момент Cisco купила компанию Sourcefire за баснословные миллиарды "Даларов". Зачем? Ну, во-первых, у Sourcefire был один из лучших в то время на рынке IPS-ов и еще был ряд интересных продуктов, которые Cisco успешно забрала себе в портфолио, например – Advanced Malware Protection, который по сути своей является End Point Detection & Response решением. Зачем? А чтобы можно было вовремя реагировать на угрозы и проводить расследования.
Ну да ладно, мы таки FirePower настраивать собрались. Первоначально Firepower выступал в качестве дополнительного модуля (виртуального в случае 5506-5555 и физического в случае 5585) к ASA. Что есть этот модуль? Этот модуль – отдельный и самобытный кусок ПО, доставшийся от Sourcefire. Отсюда следует забавный вывод: для управления этим модулем требовалась отдельная консоль управления (в идеале). А еще, логика обработки пакетов была довольной необычной, но так как экран работал с относительно небольшими скоростями, было принято решение о выносе модуля FirePower в качестве отдельного, уже не относящегося к межсетевому экрану ASA и назвали это чудо FirePower Threat Defense – где в базе используется ASA, а сверху прилеплен NGFW функционал. Новые FirePower-ы имеют огромную производительность – подробнее смотрите в даташитах.
Кратко о наших баранах или общие рекомендации
Вариации настройки платформы Firepower Threat Defense всего два (а если рассматривать ASA + FirePower сервисы, то аж три, или даже четыре – такой вот коленкор):
FirePower Management Center (FMC) – централизованное управления политиками, устройствами и событиями. Обладает автоматизацией, что упрощает настройку.
FirePower Device Manager (FDM) – является простым автономным решением для стандартных настроек правил обеспечения безопасности.
Мы же рассмотрим самую медленную, но самую богатую (по функционалу) вариацию – средство централизованного управления FMC. Она обладает многопользовательской настройкой, более продвинутым реагированием на угрозы, такой прям мини-SIEM. Также предусмотрено наследование политик (централизованный пуш конфигурации на устройства), что упрощает настройку. Перейдем непосредственно к первоначальной настройке FMC. Настройки будем рассматривать для IPS/IDS (комплексы средств для предотвращения и обнаружения угроз в локальную сеть). Чтобы максимально эффективно использовать IDS/IPS, нужно придерживаться следующих рекомендаций:
Систему необходимо разворачивать на входе защищаемой сети или подсети и обычно за межсетевым экраном (нет смысла контролировать трафик, который будет блокирован) — так мы снизим нагрузку. В некоторых случаях датчики устанавливают и внутри сегмента.
Перед активацией функции IPS следует некоторое время погонять систему в режиме, не блокирующем (IDS). В дальнейшем потребуется периодически тюнинговать правила.
Большинство настроек IPS установлены с расчетом на типичные сети. В определённых случаях они могут оказаться неэффективными, поэтому необходимо обязательно указать IP внутренних подсетей и используемые приложения (порты). Это поможет железке лучше понять, с чем она имеет дело. Но тут есть такая штука как NGIPS – система снимает профиль трафика и может сама под него подстраиваться, включая нужные правила и отключая ненужные.
Если IPS-система устанавливается «в разрыв», необходимо контролировать ее работоспособность, иначе выход устройства из строя может запросто парализовать всю сеть.
Настройте вы его уже наконец – часть 1
Итак, приступим к настройке платформы Сisco FirePower:
Устанавливаем Необходимое ПО: Его можно найти в вашем комплекте поставки, либо можете скачать с официального сайта cisco.com (при наличии у вас сервисного контракта). ПО понадобится следующее: FirePower Management Center (поддерживает ESXi и KVM) и образ для вашей железяки или же образ виртуального Firepower-а, который американцы прозвали NGFWv.
Подключаем кабели (согласно указанной ниже схеме и что неприменимо к виртуалке).
Console port – консольный порт
Management port – для подключения и настройки сети
Logical Device Management – для настройки логических устройств (можно настраивать как 1, так и все интерфейсы сразу)
Поместите FMC в сеть управления логическими устройствами. Для обновлений FTD и FMC требуется подключение к интернету. Если оборудование не новое (было кем-то использовано), необходимо стереть текущую конфигурацию следующими командами (выделены «жирным»):
Firepower-chass Firepower-chassis # connect local-mgmt
Firepower-chassis(local-mgmt)# erase configuration
Подключитесь к последовательному консольному порту, используя эмулятор терминала. Firepower 9300 включает последовательный консольный кабель RS-232 – RJ-45. Вам может понадобиться использовать кабель последовательного интерфейса USB от стороннего производителя для подключения. Используйте следующие серийные параметры:
9600 baud
8 data bits
No parity
1 stop bit
При появлении запроса войдите в систему с именем пользователя admin и паролем cisco123. Вводим только то, что выделено «жирным».
Когда появится запрос о подтверждении конфигурации, подтверждаете – просто наберите yes.
Настройте вы его уже наконец – часть 2
Далее нам необходимо произвести настройки, используя браузер. Обращаю внимание, что не каждый браузер подойдет! Настраивать можно только с управляющего компьютера, IP-адрес которого попадаем в диапазон, который указывали в конфигурации.
Заходим в браузер и в поисковую строку (строку ввода URL) вводим следующее: https://адрес_железки
Вводим имя пользователя admin и новый пароль для входа в дальнейшем. Осуществляем процедуру входа в систему.
Настраиваем NTP соединение. Оно нужно нам для синхронизации времени на всех устройствах. От этого зависит как стабильность, так и сама работа в принципе.
Заходим непосредственно в настройки и выбираем параметр использования NTP-сервера. В правом нижнем углу выберите «Add»
NTP Server (обязательное поле для заполнения) должен включать IP-адрес или имя host-сервера, Authentication Key – идентификатор от NTP-сервера. Если не знаете этот ключ, можете найти его поискав через поисковик (ntp.keys). Также можно получить его (при условии, что файла ntp.keys нет), прописав команду в консоли управления ntp-keygen -M, затем поискав тот же самый файл, вы найдете его в директории.
Нажимаем «Add» и добавляем наш NTP-сервер.
Сохраняем изменения. Заходим во вкладку «Current Time», затем «Time Zone» и выбираем свой часовой пояс из списка и после сохраняем настройки.
Настройте вы его уже наконец – часть 3. Настройка базового функционала.
Настроим интерфейсы. Для этого переходим в саму вкладку «Interfaces», расположенную у рамки окна в черной полосе. Нажимаем «Edit» для интерфейса, который собираемся настроить.
Открываем порт для работы галочкой напротив «Enable». В строке «Type» выбираем назначение интерфейса (мы будем передавать данные, поэтому выбираем пункт «data-sharing». Остальные данные заполнять не обязательно. Скажу, что там настраивается Скорость передачи, авто согласование и режим дуплекса соответственно. Лучше оставить данные параметры не настроенными, система сама перестроится для работы.
Перейдем непосредственно к настройке IPS (политика обнаружения вторжений).
Выбираем пункт Policies > Access Control > Intrusion
Далее жмем Сreate Policy (справа кнопка)
И в появившемся окне заполняем имя (Name) (обязательный параметр). Если вы не обладаете достаточными знаниями для детальной настройки IPS, воспользуйтесь рекомендуемыми фильтрами. Пункт Base Policy, в нем выбираем Maximum Detection (максимальная защита). Создаем и применяем изменения с помощью кнопки Create and Edit Policy.
IPS тут умен, гораздо умнее автора этой статьи. В ходе эксплуатации вы это заметите. А именно, что при использовании максимальной степени защиты (Maximum Detection) программное обеспечение предложит вам исключить правила, которые не нужны и просто на «холостую» тратят ресурсы вашего устройства защиты. Такие рекомендации она делает по результатам статистики. Она хранится в Policies > Access Control > Intrusion > Firepower Recommendations > Generate Recommendations
Таким образом, система адаптируется индивидуально для вашей сети.
Настроим обнаружение вирусов и зараженных файлов. Но для более адекватной работы сети, рекомендуется создать DNS «ловушку» (следующий пункт), которая покажет, на какое именно устройство пришел вредоносный файл. Если «ловушку» не создавать, то информация о зараженном файле появится в общем хранилище и определить, какое из устройств получило этот вредоносный файл (код), не представится возможным.
Переходим по пути: Policies > Access Control > Malware & File. Создаем новую политику, даем ей название. Затем добавляем правило (Add Rule). Заполнить рекомендуется так, как указано на изображении. Это общепринятое правило с максимальной степенью защиты. Нажимаем Save.
Теперь настроим DNS «ловушку». Objects > Object Management. Отыскиваем в левой колонке Sinkhole. Далее нажимаем Add Sinkhole
Заполняем таблицу. При заполнении обратите внимание на то, что данные, указанные в IPv4/6 не должны быть в вашей сети. После настройки нажимаем Save.
Далее переходим в настройку DNS политики (Policies > Access Control > DNS). Выбираем Add DNS Policy, добавляем название и сохраняем.
Нас автоматически переводит в это правило. Мы видим, 2 раздела (белый и черный листы. Нам необходимо создать и настроить своё правило. Для этого нажимаем Add DNS Rule и появляется новое окно. Заполняем его как на изображении.
В нем мы добавляем все возможные правила, рекомендуемые компанией Cisco. Выбираем все файлы и нажимаем Add to Rule.
И непосредственно здесь мы можем применить свою DNS «ловушку». Для этого в пункте Action выбираем Sinkhole. Напротив откроется новый пункт, в котором мы выбираем наш DNS «ловушку». Теперь мы сможем видеть, на какое устройства пришел вредоносный файл (код). На этом первоначальные настройки произведены. Далее производится более детальная настройка исходя из ваших потребностей.
Любое крупное приложение должно сопровождаться несколькими наборами тестов, с помощью которых можно проверить его стабильность и производительность.
Существует большое количество различных тестов, каждый из которых имеет свое назначение и охватывает определенные аспекты приложения. Именно поэтому, когда вы тестируете свое приложение, вы должны убедиться, что ваш набор тестов сбалансирован и охватывает все аспекты.
Однако есть один тип тестов, который разработчики часто предпочитают другим, и поэтому им часто злоупотребляют. Этот «сквозное тестирование» (E2E - end-to-end testing).
Что такое сквозное тестирование?
Для тех, кто только начал штурмовать мир тестирования программного обеспечения, E2E-тестирование - это проверка вашего приложения от начала до конца вместе со всеми его зависимостями.
При проведении E2E-тестировании вы создаете среду, которая будет идентична той, которую будут использовать реальные пользователи приложения. А затем вы тестируете все действия, которые могут выполнять пользователи в вашем приложении.
С помощью сквозного тестирования вы проверяете весь рабочий поток целиком, например, вход на веб-сайт или покупку товара в интернет-магазине.
Если вы будете злоупотреблять E2Е-тестирование, то вы перевернете пирамиду тестирования. Я в такой ситуации был. В одном из своих проектов я планировал охватить большую часть приложения Е2Е-тестами или, что еще хуже, воспользоваться лишь один Е2Е-тест. К счастью, я передумал. Так вот, теперь я хочу поделиться с вами тем, что заставило меня передумать.
Почему не нужно пренебрегать пирамидой тестирования?
Хаотично написанные тесты сначала могут показаться вполне пригодными, но в конце концов они таковыми не окажутся.
Мы пишем тесты для того, чтобы выиграть больше времени, и мы делаем это с помощью методы и средства автоматизации тестирования. Конечно, можно было бы самостоятельно открывать приложения и тестировать их вручную. Если бы это нужно было сделать однократно, то проблем не было бы. Но так бывает крайне редко.
Программное обеспечение постоянно обновляется. Поэтому необходимо проводить регулярные тестирования для того, чтобы оставаться в курсе последних событий. Вы, конечно, можете ежедневно запускать все тесты вручную при каждом обновлении приложения. Но если вы один раз напишите набор тестов, а затем будете его запускать каждый раз, когда нужно будет протестировать какой-то из аспектов приложения, то вы сэкономите много времени.
У каждого теста есть свое назначение. Если вы будете использовать их не по назначению, то они могут вам больше навредить, чем помочь. Это связано с тем, что в итоге вы потратите больше времени на то, чтобы написать эти тесты, и на их сопровождение, чем на разработку самого приложения. Иными словами, вы останетесь без одного из самых больших преимуществ автоматизированного тестирования.
Хорошее начало – придерживаться пирамиды тестирования. Она поможет вам определить правильный баланс в тестированиях. Эта пирамида является отраслевым стандартом и используется с середины 2000-х годов по сей день, так как все еще считается эффективной.
Значит ли это, что разработчики никогда не пренебрегают этой пирамидой? Не совсем. Иногда пирамида бывает перевернутой, где большую часть тестов составляют Е2Е, а иногда она бывает похожа на песочные часы, где очень много юнит- и Е2Е-тестов, но с очень мало интеграционных тестов.
Три уровня пирамиды тестирования
Как правило, пирамида тестирования имеет три уровня: юнит-тесты, интеграционные тесты и сквозные тесты.
Юнит-тесты
Юнит-тесты, или модульные тесты, делают акцент на самых маленьких единицах кода, таких как функции и классы.
Они короткие и не зависят ни от каких-либо внешних пакетов, библиотек и классов. В противном случае, в ход идет имитированная реализация.
Если юнит-тест дает сбой, то найти причину проблемы не так сложно. Они также имеют небольшой диапазон тестирования, что делает их простыми в написании, быстрыми в работе и легкими в сопровождении.
Интеграционные тесты
Интеграционные тесты делают акцент на взаимодействии между двумя отдельными объектами. Как правило, они работают медленнее, потому что они требуют более серьезной настройки.
Если интеграционные тесты проваливаются, то найти проблему немного сложнее, так как диапазон ошибок больше.
Они также более сложные в написании и сопровождении, в основном потому, что они требуют более продвинутое имитирование и расширенную область тестирования.
Сквозные тесты
И наконец, сквозные тесты, или E2E-тесты. Они делают акцент на рабочих потоках, от самых простых до самых сложных. Эти тесты можно рассматривать как многоэтапные интеграционные тесты.
Они самые медленные, потому что они подразумевают сборку, развертывание, запуск браузера и выполнение действий внутри приложения.
Если сквозные тесты проваливаются, то найти проблему часто бывает очень сложно, потому что диапазон ошибок увеличивается до всего приложения. В принципе, по пути могло сломаться все что угодно.
Это, безоговорочно, самый сложный тип тестов для написания и сопровождения (из трех типов, которые рассмотрели здесь) из-за огромного диапазона тестирования и из-за того, что они охватывают все приложение.
Надеюсь, теперь вы понимаете, почему пирамида тестирования была спроектирована именно таким образом. Снизу-вверх каждый уровень тестирования говорит о снижении скорости и увеличении диапазона и сложности и усложнении сопровождения.
Именно поэтому важно не забывать о том, что E2E-тестирование не может полностью заменить другие методы – оно лишь предназначено для расширения их возможностей. Назначение Е2Е-тестирования четко определено, и тесты не должны выходить за его границы.
В идеале тесты должны выявлять ошибки настолько близко к корню пирамиды, насколько возможно. Е2Е-тест предназначен для проверки кнопок, форм, изменений, ссылок, внешних процессов и вообще всех функций рабочего потока.
Тестирование с кодом VS codeless-тестирование
В целом, существует два типа тестирования: ручное и автоматизированное тестирование. Это значит, что мы можем проводить тестирования либо вручную, либо с помощью сценариев.
Чаще используют именно второй метод. Но и автоматизированное тестирование можно разделить на две части: тестирование с кодом и codeless-тестирование.
Тестирование с кодом
Когда вы проводите тестирование с кодом, вы используете фреймворки, которые могут автоматизировать браузеры. Один из самых популярных инструментов – это Selenium, но я больше предпочитаю использовать в своих проектах Cypress (только для JavaScript). И тем не менее, работают они практически одинаково.
По сути, с помощью таких инструментов вы моделируете веб-браузеры и даете им указания для выполнения различные действия в вашем целевом приложении. После чего вы проверяете, отреагировало ли ваше приложение на соответствующие действия.
Это простой пример имитации, взятый из документации Cypress. Я привел его, чтобы вы могли лучше понять, как работает этот инструмент:
Давайте посмотрим, что тут происходит:
Допустим, пользователь посещает сайт
https://example.cypress.io
Когда она нажимает на ссылку с пометкой type, URL-адрес должен добавить /commands/actions
Если он вводит «fake@email.com» в поле ввода .action-email, тогда ввод .action-email принимает значение «fake@email.com».
Codeless-тестирование
В ситуации с codeless-тестированием вы используете фреймворки на базе искусственного интеллекта, которые запоминают ваши действия. И основываясь на некоторой дополнительной информации, они проверяют, отвечает ли ваше целевое приложение на действия должным образом.
Эти инструменты часто выглядят как малокодовые платформы для разработки, где вы перемещаете различные панели. Один из таких инструментов – TestCraft, codeless-решение, разработанное на платформе Selenium.
Как правило, эти инструменты стоят дороже из-за того, то такие функции, как создание, сопровождение и запуск тестов выполняются с помощью простого перемещения панелей, а также из-за того, что для проведения тесто не нужно уметь писать программный код. Но я упомянул здесь про TestCraft, потому что у них есть бесплатная версия, которая включает в себя практически все.
Конечно, если речь идет о скорости и деньгах, то codeless-решение может оказаться вам больше по душе, но они все еще достаточно новые. Поэтому они пока не могут иметь ту сложность наборов тестов, которой можно достичь, написав код самостоятельно.
Если в целевом приложении есть очень сложные рабочие потоки, которые включают в себя несколько подвижных частей, то вам больше подойдет классический вариант тестирования. Но если сложных потоков нет, то вы можете воспользоваться codeless-решением.
Подведение итогов
Написание тестов – обязательное требование для любого приложения. Если вы будете следовать всем правилам и писать наборы тестов исходя из их типов, то они только улучшат ваше приложение, а также их будет довольно просто написать и сопровождать.
Использовать сквозные тесты, как и любые другие, следует только для того, для чего они предназначены. Они предназначены для тестирования рабочего потока приложения от начала и до конца путем воспроизведения реальных пользовательских сценариев. Но помните, что большинство ошибок следует выявлять как можно ближе к корню.