Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1014 сообщений
Cообщения с меткой

bash - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Консольные помощники для работы с Kubernetes через kubectl

Вторник, 07 Ноября 2017 г. 14:42 (ссылка)

image

Kubectl — основной консольный интерфейс для взаимодействия с Kubernetes и, безусловно, важный инструмент в руках любого администратора/DevOps-инженера, причастного к эксплуатации таких кластеров. Если вы пользуетесь им каждый день и делаете это по-настоящему активно, то, как это свойственно ИТ-специалистам, наверняка задумывались о способах упрощения/автоматизации своих манипуляций. Благо, это мир сисадминов, Open Source и консоли, так что в нём, конечно, уже нашлись и те, кто не только задумывался об этом, но и воплотил свои потребности в жизнь — в виде утилит, доступных теперь и всем «коллегам по цеху». О них и пойдёт речь в этом небольшом обзоре. Читать дальше ->

https://habrahabr.ru/post/341606/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] CI: непрерывная интеграция за 5 минут

Вторник, 07 Ноября 2017 г. 13:18 (ссылка)

Всем здоровья, товарищи хаброжители. Совсем недавно столкнулся с необходимостью поднять и настроить сервис «Непрерывной интеграции» (далее CI) на одном очень небольшом проекте, очень косвенно связанном с моей работой. Время не поджимало, потому решил попробовать что-то новенькое (ранее использовал только Travis и Jenkins). Главным критерием выбора была: «простота и скорость развертывания системы на интеграционном сервере».



Под катом небольшая история и получившийся в ходе нее инструмент для CI, написанный за два вечера на Bash.
Читать дальше ->

https://habrahabr.ru/post/341818/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Дюжина приемов в Linux, которые действительно сэкономят уйму времени

Воскресенье, 22 Октября 2017 г. 12:22 (ссылка)

image


Однажды вечером, перечитывая Джеффри Фридла, я осознал, что даже несмотря на всем доступную документацию, существует множество приемов заточенных под себя. Все люди слишком разные. И приемы, которые очевидны для одних, могут быть неочевидны для других и выглядеть какой-то магией для третьих. Кстати, несколько подобных моментов я уже описывал здесь.



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



Под катом — дюжина приемов в командной строке — из личного опыта.
Читать дальше ->

https://habrahabr.ru/post/340544/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Играючи BASH'им вместе

Вторник, 03 Октября 2017 г. 23:45 (ссылка)

Игра на bash'е с поддержкой мультиплеера, миф или реальность?



image



Истина где-то тут. Разоблачительный текст далее.
Читать дальше ->

https://habrahabr.ru/post/339268/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Своя система сборки на Linux

Понедельник, 25 Сентября 2017 г. 18:19 (ссылка)






Ryder95


сегодня в 18:19

Разработка





Своя система сборки на Linux










    image



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



    Мотивация





    Проблема сборки и запуска проекта на разных машинах преследовала меня всегда. Для того, чтобы реалистично смоделировать работу разрабатываемого сайта на локальной машине нужно установить Web-сервер, Application-сервер, возможно, к ним присоединится какой-нибудь ещё промежуточный сервер, установить базу данных, настроить базу данных. Для того, чтобы установить тестовый сайт на тестовый сервер, нужно проделать такую же работу. И позже тоже самое с рабочим сервером.

    Кажется, что проблема решается легко — напиши все команды в файл и просто запускай его везде. Решение относительно хорошее, но не идеальное, и вот почему. К примеру, на одном из серверов уже установлены нужные пакеты и база данных там готова. Но не до конца, к ней не применены последние миграции. Придётся открывать файл с командами и вытаскивать оттуда нужные, дабы не получить ошибку или чтобы что-то не сломать.



    Но это не такая серьёзная проблема, большую проблему я определил для себя при работе с Django. Django, как известно, при его запуске висит в памяти, и если код изменён — эти изменения никак не повлияют на сайт. Приходится постоянно перезапускать сервер. Несложно. А если изменены модели, нужно ещё и миграции создать и применить? А если настройки веб-сервера изменены, то нужно и их ещё применить и перезапустить веб-сервер? А если всё вместе, а проект я открывал месяц назад и абсолютно не помню, что я там менял и мне бы «сделать хорошо», но я не хочу утомительно вбивать все команды? А если проект огромный и я не хочу тратить время на лишние команды при запуске и сборке? И таких «А если...» может быть тьма тьмущая.



    Решение пришло само — нужна автоматизация, сборщик проектов. Конечно же, на Linux. Погуглив, я нашёл уйму сборщиков проектов… Для одного языка или одной технологии. Ничего действительно универсального, чтобы прописал команды — и он их по надобности запускает — нет. Есть cmake, но его я не взял, потому что придумал решение получше)



    В этот момент была создана первая схема велосипеда. Сначала я написал в файл все команды, но при малейших изменениях перезапуск всего занимал длительное время — это раздражало. Сначала смирился. Потом хотел, чтобы у скрипта были настройки, написал в первых строках переменные и описал алгоритм их изменения через аргументы запуска скрипта. Потом мне всё же захотелось не выполнять некоторые команды, если этого не требуется, и я сделал функции проверки. Потом пришла идея разграничить команды, некоторые объединить друг с другом. Объединённые команды я назвал «target». В скрипт отправляется имя цели, а потом она выполняется. Оказалось, что некоторые цели неспособны выполнится без выполнения других целей — так появилась иерархия. Потом функции проверки команд превратились в функции проверки целей. Потом захотелось упростить работу с установкой пакетов, и была создана сущность «package».



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



    Результат





    Итоговым рабочим вариантом получился bash скрипт в 400 строк, который я назвал xGod. Я так его назвал, потому что этот файл стал незаменим для меня при работе, как воздух.

    Как работает xGod:

    Запускается из консоли — bash ./xgod build.xg run

    build.xg — это файл сборки, в котором прописаны все цели и дополнительные функции

    run — это цель, которую нужно выполнить



    Из чего состоит build.xg:

    1. Из обычных строк на языке bash — они выполняются последовательно по мере считывания файла

    2. Из целей

    Например:

    target syncdb: virtualenv createmysqluser
    source "$projectpath/venv/bin/activate"
    python3 "$projectpath/manage.py" makemigrations
    python3 "$projectpath/manage.py" migrate
    deactivate


    syncdb — название цели; virtualenv createmysqluser — это цели, которые надо выполнить до выполнения цели syncdb, так называемые зависимости; всё остальное — это обычный bash код, которым и достигает саму цель.

    3. Пакеты:

    Например:

    package gunicorn: python
    all:
    name: python3-gunicorn


    gunicorn — название пакета (или цели, потому что для скрипта это такая же цель); python — зависимость; all — это название дистрибутива, к которому применяются вложенные настройки, all означает, что данные настройки применяются ко всем дистрибутивам без исключения, в данный момент реализована поддержка только debian и ubuntu, потому что с другими я не работал; name — это название пакета, используемое для установки.

    4. Функции проверки:

    Например:

    check syncdb()
    # any code
    return 1 # or return 0
    endcheck


    Функция проверки позволяет проверить, нужно ли выполнять цель syncdb или нет. Сохраняется и выполняется она как обычная функция, возвращает 1 (если цель надо выполнять) или 0 (если цель не надо выполнять)



    Также была написана система поддержки расширений. Цели package как раз-таки являются расширениями. Синтаксис расширений не сильно отличается от синтаксиса файлов сборки, в нём могут присутствовать:

    1. Обычные команды на языке bash

    2. Обязательно функция действия.

    Например:

    action
    # any code with $1
    endaction


    Это функция принимает на вход имя цели и выполняет её по своим правилам. Все внутренности цели она может получить из переменной ${TARGETS[$1]}

    3. Функция проверки цели

    Например:

    check
    # any code with $1
    return 1 # or return 0
    endcheck




    Ещё применения





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



    В следствии такого применения скрипта его главным условием было — это минимальные зависимости для запуска. Поэтому вместо Python или C++ он написан на bash — чтобы его можно было запустить из любой среды Linux без дополнительных действий. Единственный минус — bash должен быть не меньше 4 версии, так как там ассоциативные массивы не поддерживаются.



    Также получает на вход имя цели и проверяет, нужно ли её выполнять. Если нужно, то обязана вернуть 1, а если нет, то 0



    Ссылку на код оставлю здесь


    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/338698/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Быстрая разработка скриптов мониторинга с помощью Bash, Outthentic и Sparrow

    Вторник, 19 Сентября 2017 г. 14:10 (ссылка)






    alexey_melezhik


    сегодня в 14:10

    Разработка





    Быстрая разработка скриптов мониторинга с помощью Bash, Outthentic и Sparrow






    • Tutorial




    В данном посте я расскажу о том, как просто и быстро писать различные скрипты проверки состояния инфраструктуры с помощью инструментов Bash, Outthentic и Sparrow ...



    Задача — у нас есть сервер, на который мы устанавливаем приложения и делаем настройку конфигурации. Хочется написать скрипт, который быстро даст нам ответ, что с сервером все хорошо, и приложение настроено и работает корректно. Этакий smoke тест, который будет нам полезен, когда мы будем заниматься поиском проблем или же просто проверять, что очередной деплоймнет ничего не сломал. Предвидя возможные вопросы, я знаю, что уже существуют инструменты, которые делают что-то подобное ( inspec ), тем не менее, хочу рассказать об альтернативном походе. ( Будет интересно сравнить ).



    Выбор инструментария



    Итак, почему Bash? Потому что он достаточно прост в использовании и позволяет быстро и эффективно писать разного рода скрипты, imho я бы не стал использовать Bash для более сложных задач, но для данного рода проблем он вполне подходит.



    Затем, что такое Outthentic и как он нам здесь пригодится? Outthentic — это фреймворк для написания скриптов, позволяющий быстро написать, настроить и запустить ваш скрипт ( в данном случае, написанный на Bash, но можно и на других языках ), так же, что немаловажно, Outthentic имеет встроенный DSL, подходящий под написание скриптов в стиле автоматизированных тестов, что может быть удобным при написании скриптов мониторинга.



    И последнее — почему ( или что-то такое ) Sparrow и как он нам поможет? Sparrow — это платформа и среда выполнения пользовательских скриптов, позволяющая распространять и настраивать готовые скрипты в виде т.н. Sparrow плагинов. Основной выхлоп в том, что когда наш скрип написан и оттестирован, вы можете упаковать его в виде плагина, загрузить в Sparrow репозитарий и передать далее в отдел эксплуатации и/или любым другим коллегам, которые захотят воспользоваться вашим скриптом.



    Практический пример



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




    • запущен tomcat, то есть виден в списке процессов




    • http запросы на некоторые ресурсы приложения ( развернутого на сервере )

      возвращают успешный http код (200) — GET 127.0.0.1:8080/healthcheck




    • с целевого сервера доступен сервер баз данных (192.168.0.2), на уровне доступа по tcp порту ( очень часто из-за некорректно настроенной политики безопасности это может быть не так, что приводит к неработоспособности приложения )



    Да, и важно отметить, что все проверки выполняются прямо на целевом сервере:



    $ ssh   target-server bash 
    $ bash /path/to/check/script.bash


    Bash скрипт



    В данном случае скрипт будет тривиальным:



    $ cat script.bash

    #!/bin/bash

    ps uax | grep tomcat | grep -v grep

    echo; echo

    timeout 5 curl -sL 127.0.0.1:8080/healthcheck -w "GET /healhcheck --- %{http_code}\n" -o /dev/null

    echo; echo

    timeout 5 bash -c "echo OK | telnet 192.168.0.2 3306"


    Запустив скрипт на целевом сервере получим в выводе что-то похоже на это: ( на данном этапе пока никаких проверок не происходит, просто убедимся, что скрипт отрабатывает ):



    $ bash script.bash

    GET /healhcheck --- 200

    tomcat 8264 0.0 32.1 2222884 326452 ? Sl Sep14 4:04 /usr/lib/jvm/java-1.8.0/bin/java -Djava.util.logging.config.file=/usr/share/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xmx128M -Djava.awt.headless=true -Djava.endorsed.dirs=/usr/share/tomcat8/endorsed -classpath /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar -Dcatalina.base=/usr/share/tomcat8 -Dcatalina.home=/usr/share/tomcat8 -Djava.io.tmpdir=/usr/share/tomcat8/temp org.apache.catalina.startup.Bootstrap start

    Trying 192.168.0.2 ...
    Connected to 192.168.0.2.
    Escape character is '^]'.
    Connection closed by foreign host.


    Проверка вывода скрипта



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



    Для начала установим пакет как CPAN модуль:



    $ cpanm Outthentic


    Далее слегка модифицируем наш скрипт, что бы его можно было запускать через Outthentic:




    • переименуем скрипт в strory.bash — это соглашение на имеование скриптов во фреймворке Outthentic:



    $ mv script.bash story.bash



    • запустим скрипт через консольный клиента strun, который поставляется вместе с фреймворком Outthentic и собственно запускает скрипты:



    $ strun


    Получим вывод, аналогично тому, когда мы запускали скрипт напрямую. Пока, что польза Outthentic не очевидна. Доходим до использования DSL. Создадим несколько простых проверочных правил для валидации вывода скрипта и положим правила в файл story.check:



    $ cat story.check

    GET /healhcheck --- 200
    tomcat8
    Connected to 192.168.0.2


    Запустим снова strun:



    $ strun 
    2017-09-18 17:39:55 : [path] /
    GET /healhcheck --- 200

    tomcat 8264 0.0 32.1 2222884 326452 ? Sl Sep14 4:04 /usr/lib/jvm/java-1.8.0/bin/java -Djava.util.logging.config.file=/usr/share/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xmx128M -Djava.awt.headless=true -Djava.endorsed.dirs=/usr/share/tomcat8/endorsed -classpath /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar -Dcatalina.base=/usr/share/tomcat8 -Dcatalina.home=/usr/share/tomcat8 -Djava.io.tmpdir=/usr/share/tomcat8/temp org.apache.catalina.startup.Bootstrap start

    Trying 192.168.0.2 ...
    Connected to 192.168.0.2.
    Escape character is '^]'.
    Connection closed by foreign host.
    ok scenario succeeded
    ok text has 'GET /healhcheck --- 200'
    ok text has 'tomcat8'
    ok text has 'Connected to 192.168.0.2'
    STATUS SUCCEED


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



    $ strun --format production


    Вот как будет выглядеть отчет в случае если, по каким-то причинам, у нас не запущен tomcat сервер:



    $ strun  --format production
    2017-09-18 17:44:43 : [path] /
    not ok text has 'tomcat8'
    GET /healhcheck --- 200

    Trying 192.168.0.2 ...
    Connected to 192.168.0.2.
    Escape character is '^]'.
    Connection closed by foreign host.
    STATUS FAILED (2)


    Параметризация скрипта мониторинга



    Outthentic еще удобен и тем, что он позволяет просто добавлять и настраивать входные параметры для ваших скриптов. Допустим, чисто теоретически, мы захотим задавать хост и порт для сервера баз данных.



    Добавим дефолтные значения входных параметров через suite.yaml — файл для хранения дефолтных настроек в терминологии Outthentic:



    $ cat suite.yaml
    ---
    db_server:
    ip_address: "192.168.0.2"
    port: 3306


    В данном случае иерархия конфигурационного файла может быть произвольной, просто я хочу показать, как легко и просто с помощью Outthentic передавать входные параметры, описанные в виде иерархический структуры данных и использовать их даже внутри Bash скриптов ( не применяя дополнительного парсинга ):



    Чуть-чуть изменим скрип мониторинга, что бы он брал свои входные параметры из-вне :



    $ cat script.bash

    #!/bin/bash

    db_server_address=$(config db_server.ip_address)
    db_server_port=$(config db_server.port)

    # ... следующие строчки кода остаются неизменными
    # ...

    timeout 5 bash -c "echo OK | telnet $db_server_address $db_server_port $db_server_port"


    Теперь мы можем запустить наш скрипт с дефолтными параметрами:



    # для сервера баз данных будут использоваться ip address 192.168.0.2 и порт 3306
    $ strun


    Или же переопределить параметры через командную строку:



    $ strun --param db_server.ip_address=192.168.0.3 --param db_server.port=3307


    Идем дальше, все что нам осталось сделать — это передать скрипт в эксплуатацию всем заинтересованным лицам, для этого нам понадобится Sparrow.



    Дистрибуция скрипта в виде Sparrow плагина



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



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



    $ git init .
    $ git add .
    $ git commit -a -m "outthentic monitoring script"


    Добавив основные файлы проекта (story.bash и story.check ), нам остается настроить файл с мета данными ( который собственно и дает понять, что это не просто скрипт, а Sparrow плагин ) :



    $ cat sparrow.json

    {
    "name" : "server-check"
    "description" : "check server health"
    }


    На самом деле файл с мета данными может содержать гораздо большее число параметров, но мы ограничимся здесь для простоты минимальным набором.



    Окей, мы фактически сделали наш первый Sparrow плагин, осталось отправить файлы в git remote:



    git add sparrow.json
    git commit -a -m "add sparrow meta file"
    git remote add origin $remote-git-repository
    git push -u origin master


    Использование готового скрипта мониторинга как Sparrow плагина



    Это самая интересная часть в том смысле, что он показывает как Sparrow облегчает процесс установки и интеграции ваших скриптов сторонними командами.



    Для начала, что бы использовать созданный нами плагин на каком-то целевом сервере, нам необходимо установить на этом сервере Sparrow клиент:



    $ cpanm Sparrow  


    Далее все просто, т.к. плагин — приватный и не будет загружен с общего репозитариия, уведомляем об этом Sparrow:



    $ echo "server-check $remote-git-repository" >> ~/sparrow.list


    Пара значений которую мы должны положить в локальный индексный файл ~/sparrow.list это название плагина ( не обязательно должно совпадать с тем, что мы использовали в предыдущей части и URL удаленного репозитария, где лежит исходный код плагина )



    Теперь обновляем индекс sparrow, что бы стал доступен добавленный нами плагин:



    $ sparrow index update 


    И устанавливаем сам плагин:



    $ sparrow plg install server-check


    Теперь мы можем запустить плагин как есть:



    $ sparrow plg install server-check


    Или же, передав ему параметры:



    $ sparrow plg install server-check --param db_server.ip_address=192.168.0.3 --param db_server.port=3307


    И наконец-то, все тоже самое можно запустить в виде Sparrow задачи:



    $ sparrow project create monitoring
    $ sparrow task add monitoring app1 server-check
    $ sparrow task ini monitoring/app1

    ---
    db_server:
    ip_address: "192.168.0.2"
    port: 3306

    ---

    $ sparrow task run monitoring/app1


    Последний вариант запуска удобен тем, что вы можете создать несколько задач ( с разными конфигурациями ) для запуска одного и того же плагина. По сути задача — это именованная конфигурация запуска Sparrow плагина, а проект — группа задач.



    PS



    На этом все. Если кому-то будет интересно, вот о чем я еще не сказал:




    • приватные Sparrow репозитарии можно настраивать не только через локальные индекс файлы ~/sparrow.list ( что неудобно при большом количестве плагинов ), но и через Sparrow::Nest — API управления приватными Sparrow репозитариями.




    • Sparrow плагины можно запускать удаленно на серверах ( через ssh ) с автоматической предустановкой Sparrow клиента — добро пожаловать в проект Sparrowdo. Там есть еще Perl6 API для Sparrow и много другого (-: !




    • Outthentic DSL позволяет создавать гораздо более сложные и интересные проверочные правила, чем просто соответствие подстроке. Среди них — проверка по Perl5 regexp, проверка по диапазону и последовательности строк, а так же динамическая генерация правила с помощью языков программирования общего назначения.



    Как всегда — вопросы, замечания, предложения, конструктивная критика — приветствуется.



    С уважением.



    Алексей



    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/338144/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Играючи BASH'им дальше

    Среда, 13 Сентября 2017 г. 20:33 (ссылка)

    https://habrahabr.ru/post/337896/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    У Вас в организации много разных принтеров и необходимо со всех собрать количество отпечатков?

    Четверг, 07 Сентября 2017 г. 11:17 (ссылка)

    В нашей компании 4 офиса в каждом по 3-4 этажа, много кабинет и почти в каждом стоит 1-3 принтера и МФУ. Статья о том, как с помощью bash зная лишь ip-адреса принтеров автоматизировать собор с них количества отпечатков.

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


    Читать дальше ->

    https://habrahabr.ru/post/337242/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Zabbix: LLD-мониторинг служб FlexLM

    Вторник, 05 Сентября 2017 г. 14:56 (ссылка)

    image



    Эта статья — более детальная проработка предыдущей. Теперь шаблон унифицирован для использования как в Windows (PowerShell), так и в Linux (Bash). Если вы использовали предыдущий шаблон, то все должно встать болт-он.

    Что умеет: находить серверы/лицензии, считывать состояния серверов, считывать суммарное и использованное количество лицензий, в случае ошибок передает коды состояний (строку с описанием) и рапортует о них.



    Схема все та же:


    • Шаблон

    • Скрипты (PowerShell/Bash)

    • Правильная настройка агента


    Читать дальше ->

    https://habrahabr.ru/post/336570/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

    Следующие 30  »

    <bash - Самое интересное в блогах

    Страницы: [1] 2 3 ..
    .. 10

    LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
    О проекте: помощь|контакты|разместить рекламу|версия для pda