Ansible Ltd.

Всем привет.

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

Джейку не спалось. В пол-пятого утром он вышел на свежий воздух и обнаружил в своем почтовом ящике рекламный буклет формата А5.

Броский дизайн очередной рекламной кампании с ярким текстом: 

"Уважаемый клиент! Мы - логистическая кампания Будущего, которое для вас может уже стать Настоящим. Мы - это новое слово в доставке чего угодно и куда угодно. Для Вас сегодня Акция - первые три посылки для Вас совершенно бесплатны. Любой формат, любое место назначение, 100% гарантия. Наш сервис Вас приятно удивит!"

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

"Наша миссия - сокращать расстояния!".

Буклет уже было готов был полететь в урну, но уж больно наклейки были хороши. Поэтому Джейк решил поделиться одной из них с Максом. Он взял конверт, запечатал в него чистый лист бумаги, написал сверху адрес и прикрепил наклейку. Он тут же понял что клеить ее, пожалуй, и не следовало, но... через секунду пискнул телефон вещающий о получении новой sms. Джейк, больше сейчас мечтающий про утренний кофе, и потому нехотя потянулся за телефоном,  взял его и прочитал текст:

"Ваша посылка доставлена. Мы рады что вы с нами."

В отправителях sms значилось: Ansible Ltd., четверг.

Джейк быстро вернул взгляд на стол, конверта там не оказалось. Чисто по привычке заглянул под стол, пошарил взглядом направо налево. Конверта не было. Прочитал еще раз смс. Слабо веря в новые веяния логистики он через пару минут решил еше раз перечитать буклет. От чтения его отвлек звонок Макса. Тот спрашивал что у него за шутки в 5-ть утра присылать чистые листы бумаги..., кое как промямлив в ответ, Джейк погрузился в раздумья: 

- Но сегодня пятница. - Я запечатал конверт полчаса тому.

- Хм, и что за странная sms? Эта фирма доставки не придает значения ни часам ни минутам, а? Может они и время считают по другому?

- Спокойно, это только доказывает, что их логистика находится в тропической стране. В тропиках время почти ничего не значит. Отметка "четверг" свидетельствует, что Ansible Ltd. в Центральной Америке. Если бы эта страна находилась в Индии или еще где-нибудь на востоке, в sms была бы "среда", согласен?

- Точно. Супер-скоростная почта! - воскликнул Джейк. - Еще бы! Да "Новая почта" ей в подметки не годится. Если за время, прошедшее от того, как я получил sms, до момента, когда оно упало в ящик Макса, письмо пропутешествовало не просто отсюда до него, а сначала побывало в Центральной Америке, было обработано и только потом попало к нему, тогда его средняя скорость будет...

- Ок, я знаю как вас вычислить. Посмотрим как вы поступите с недоставкой! - Джейк взял случайную книгу с полки, аккуратно завернул ее и написал только что выдуманный им адрес: "Mr. Jake Faraday, 711, Pаradise Road, Nirvana». Но чтобы вероятность возврата посылки была стопроцентной он указал в качестве адресата себя. Он прикрепил вторую наклейку и положил книгу на стол не сводя с нее взгляда. Секунда, другая, он даже зевнул, но она не исчезла.

- Ага, все таки развод! - заиграли эмоции у Джейка.- Какие только фокусы не придумают во времена карантина.

Еще через секунду пришла sms:

"Возврат отправителю. По указанному адресу получатель временно не проживает. Мы рады что вы с нами. Ansible Ltd., пятница."

- Вот черт! - вырвалось у Джейка. - Они издеваются? Что значит "временно не проживает"? Адрес был взят с потолка!

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

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

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

Телефон принял очередную sms: 

"Ваша посылка доставлена. Мы постоянно развиваем наш сервис - теперь в акции участвуют посылки с доставкой в места назначения где время отличается от вашего более чем на 24 часа. Мы рады что вы с нами. Ansible Ltd., суббота."

Разведка из открытых источников, часть 3.

Всем привет.

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

Сканирование сети является неотъемлемой частью сетевых атак. Для успешной защиты необходимо понимать, как осуществляется обнаружение узлов в сети. Мы проведем исследование тех служб, которые при­меняются в сети. Сначала рассмотрим, как злоумышленник может идентифицировать работающие узлы. Затем перей­дем к тому, как определить, какие службы запущены на дан­ных машинах. Для идентификации активных узлов в локальной сети можно использовать различные протоколы сетевого и транспортного уровня, такие как ICMP, UDP и TCP. Но обо всем по порядку.

ICMP как простой инструмент исследования сети

Протокол ICMP служит для выявления проблем, связан­ных с сетевым уровнем. Как правило, в локальных сетях его не блокируют, так как он часто используется самими си­стемными администраторами для поиска неполадок в сети.

Прежде всего рассмотрим основные принципы работы данного протокола. Сообщения ICMP передаются в виде IP- датаграмм, то есть к ним прибавляется заголовок IP. 

Существует несколько типов сообщений ICMP, каждый имеет свой формат, при этом все они содержат следующие три поля:

-    8-битного целого числа, обозначающего тип сообще­ния (TYPE);

-    8-битного поля кода (CODE), который конкретизирует назначение сообщения;

-    16-битного поля контрольной суммы (CHECKSUM).

Все типы сообщений ICMP можно условно поделить на две группы.

-    Сообщения об ошибках (например, Destination Unreachable).

-    Запросы и ответы (например, Echo Request и Echo Reply).

Начнем с рассмотрения сообщений об ошибках. Они содержат заголовок и первые 64 бита данных пакета IP, при передаче которого возникла ошибка. Это делается для того, чтобы узел-отправитель смог более точно проана­лизировать причину ошибки, так как все протоколы при­кладного уровня стека TCP/IP содержат наиболее важную информацию для анализа именно в первых 64 битах своих сообщений. Для сообщений об ошибках задействовано поле кода. В основном для исследования сети используют­ся Echo Reply, Echo Request и Timestamp.

Наилучшим методом определения доступности узла явля­ется посылка сообщения ICMP Echo (Туре 8). Если система работает и отсутствует фильтрация графика данного типа, то в ответ придет сообщение ICMP Echo Reply (Type 0).

Идентификация (то есть обнаружение) сетевых уст­ройств с помощью протокола ICMP может быть выполнена двумя способами.

-   посылкой запроса, получением ответа;

-   вызовом ситуации ошибки, получением сообщения об ошибке.

В основу идентификации заложен следующий принцип. Узел, отправляющий ICMP-запрос, устанавливает значения полей Identifier, эти значения позволяют определить ответы, пришедшие от разных узлов. А для того, чтобы отличить не­сколько ответов, пришедших от одного узла, используется поле Sequence Number. В поле Code записывается ноль, поле данных произвольно (например, алфавит). Отвечаю­щая сторона должна заменить значение поля Туре на 0 и от­править датаграмму обратно.

Для выполнения обнаружения узла обычно используется утилита ping, входящая в состав большинства ОС. В качест­ве параметра ping указывается IP/имя, и в результате получа­ем ответ удаленной системы. Однако у нее есть существен­ный недостаток - все узлы опрашиваются последовательно, что заметно увеличивает продолжительность опроса.

Поведенческие параметры в Ansible.

Всем привет.

Для описания хостов в файле реестра Ansible (Ansible.cfg) необходимо явно указывать имя хоста(или IP-адрес) и порт, к которому будет подключаться SSH-клиент Ansible. Это может быть важно если вы управляете хостами с помощью, например, системой Vagrаnt. В Ansible такие перемененные называются поведенческими параметрами (см. таблицу).

ansible_connection

Ansible поддерживает несколько транспортов - механизмов подключения к хостам. По умолчанию используется транспорт smart. Он проверяет поддержку локальным SSН-клиентом функции ControlPersist. Если SSH-клиент поддерживает ее, Ansible использует локальный SSH-клиент. Если локальный клиент не поддерживает ControlPersist, тогда транспорт smart будет использовать библиотеку SSH-клиента на Python с названием Paramiko.

Пользовательский модуль в Ansible.

Всем привет.

На данный момент вам может начать казаться, что управление сетевыми средствами в Ansible во многом зависит от обнаружения правильного модуля для своего устройства. Модули предоставляют некий способ абстрактного взаимодействия между управляемым хостом и самой управляющей машиной, в то время как он делает для вас возможным сосредоточиться на самой логике вашей работы. До этого момента мы знаем что все основные производители предоставляют некий широкий диапазон поддержки модулей для Cisco, Juniper и Arista.

Рассмотрим в качестве примера модули Cisco Nexus - помимо конкретных задач, таких как управление соседним BGP (nxos_bgp) и сервером aaa (nxos_aaa_server), большинство производителей также предоставляют способы исполнения произвольного отображения (nxos_config) и настройки (nxos_config) команд. 

Но что если используемое нами в настоящий момент устройство не имеет прямо сейчас никаких модулей, которые мы бы могли найти в сети? 

Поэтому мы рассмотрим способ которым можно устранить такую ситуацию написав свой собственный пользовательский модуль.

1-й пользовательский модуль.

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

Различия между grep, egrep и fgrep.

Всем привет.

Одним из известных инструментов поиска в Linux системах, которые можно использовать для поиска всего, будь то файл или строка или несколько строк в файле, - это утилита grep. Он очень обширен в функциональности, за счет большого количества поддерживаемых им опций, таких как: поиск с использованием строкового шаблона или регулярных выражений шаблон или perl based регулярных выражений  и т.д.

Из-за его различных функциональных возможностей инструмент grep имеет множество вариантов, включая egrep (Extended GREP), fgrep (Fixed GREP), pgrep (Process GREP), rgrep (рекурсивный GREP) и т.д. Но эти варианты имеют незначительные отличия от оригинального grep. Давайте разберемся с различиями между тремя основными вариантами: «grep», «egrep» и «fgrep». Чтобы мы знали, что выбирать в соответствии со своими требованиями.

Некоторые специальные метасимволы grep:

+ - эквивалентно одному или нескольким вхождениям предыдущего символа.

? - это означает хотя-бы одно повторение предыдущего символа. Так запись «a?» будет соответствовать «a» или «aa».

(- начало выражения чередования.

) - конец выражения чередования.

| - сопоставление любого из выражений, разделенных символом ‘|‘. Например: «(a | b) cde» будет соответствовать «acde», либо «bcde».

{- этот метасимвол указывает начало спецификатора диапазона. Например: «a {2}» соответствует вхождению «aa» в файле 2 раза.

} - этот метасимвол указывает конец спецификатора диапазона.

Некоторые основные различия между grep, egrep и fgrep можно выделить следующим образом. Для этого набора примеров мы принимаем файл, в котором выполняется операция:

grep is acommand that can be used on unix-like systems. 

it searches for any string in list of strings or file. 

It is very fast. 

(f|g)ile 

Zip в командной строке Windows 10.

Всем приветик. 

А у меня новость. Новость для меня, но может и для вас.) Ну то что Windows 10 умеет открывать и создавать zip-архивы из коробки вы наверняка знаете. Но вчера мне понадобилось это же сделать из командной строки. Вот так вот, а здесь и оказался сюрприз.

Традиционно это можно сделать в Powershell:

# example 1

Compress-Archive in.txt out.zip

# example 2

Expand-Archive out.zip

А в строке вот так:

# example 1

tar.exe -a -c -f out.zip in.txt

# example 2

tar.exe -x -f out.zip

Что? Не может быть - tar?! Да, именно так - теперь tar присутствует и в Windows 10. Но если вам такое соседство противно, то ставьте бесплатный 7-Zip и пользуйтесь им:

"C:\Program files\7-Zip\7z.exe" e d:\dest\out.zip

Успехов.

Читаем журналы Linux #5 - ротация.

Всем привет.

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

Linux использует понятие «ротации» журналов вместо их очистки или удаления. При ротации создается новый каталог, а старый переименуется и при необходимости сжимается. Таким образом, журналы имеют несколько старых версий. Эти файлы будут возвращаться в течение определенного периода времени в виде так называемых backlog-ов. Как только будет получено определенное количество backlog-ов, новая ротация удалит самый старый журнал.

Ротация выполняется при помощи утилиты «logrotate».

Конфигурационный файл logrotate.

Как и rsyslog, logrotate зависит от конфигурационного файла по имени logrotate.conf, который находится в /etc.

Vagrant и proxy.

Всем привет.

Используя vagrant в своей DevOps-практике я столкнулся с проблемой его работы через прокси. Установив версию vagrant 2.2.10 я попытался добавить бокс alpine-сборки Linux:

vagrant box add generic/alpine38

На что получил ошибку resolving-а в отношении портала vagrant. Тогда я по подсказке самого портала прописал в моем окружении переменные для vagrant:

set http_proxy=http://UserName01:password10@proxy2.forza.com:9090

set VAGRANT_HTTP_PROXY=%http_proxy%

set VAGRANT_HTTPS_PROXY=%http_proxy%

set VAGRANT_NO_PROXY="127.0.0.1"

И попробовал добавить бокс alpine-сборки еще раз. Увы, ошибка resolving-а повторилась.

Тогда я переключил vagrant в режим отладки:

VAGRANT_LOG=info vagrant up

vagrant up --debug &> vagrant.log

И получил вот такую вот строку в конце продолжительного журнала vagrant.log:

C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.6.0/net/http/response.rb:122:in 

`error!': 407 "authenticationrequired" (Net::HTTPServerException)

Что говорит о том что моему vagrant-у нужна авторизация для того чтобы пробиться в интернет.

В одной из веток портала я нашел информацию что для работы vagrant через проски может помочь плагин vagrant-proxyconf. Для его использвания достаточно указать в своем vagrantfile следующее: 

  config.vm.box = "alpine/latest"

  if Vagrant.has_plugin?("vagrant-proxyconf")

     config.proxy.http     = "http://UserName01:password10@proxy2.forza.com:9090"

     config.proxy.https    = "http://UserName01:password10@proxy2.forza.com:9090"

     config.proxy.no_proxy = "localhost,127.0.0.1,.example.com"

  end

Замечательно. "Наконец то решение!" решил я. И поспешил его установить.

Я пробовал так:

vagrant plugin install vagrant-proxyconf

И так:

vagrant plugin install --plugin-clean-sources --plugin-source https://rubygems.org vagrant-proxyconf

И даже так:

vagrant plugin install C:\HashiCorp\Vagrant\vagrant-proxyconf-2.0.10.gem

Меня ждало разочарование. Оказалось чтобы установить проски-плагин vagrant требует все тот же прокси. Круг замкнулся. Попытка решить мою проблему через issue с разработчиком к результату не привела.

Возможно вы знаете ответ?

Читаем журналы Linux #4 - rsyslog.

Всем привет.

Центром механизма журналирования является демон Rsyslog:  (R)ocket-fast (Sys)tem for (log) processing. Данный сервис отвечает за прослушивание зарегистрированных сообщений различных частей системы Linux и маршрутизацию сообщения к соответствующему журналу в каталоге /var/log. Он также может передавать зарегистрированные сообщения другому серверу Linux. Весьма подробно настройка rsyslog показана здесь.

Особенности Rsyslog:

-многопоточный

-TCP, SSL, TLS, RELP, etc.

-сохранение логов в базы данных (MySQL, PostgreSQL, Oracle, etc.)

-фильтрация по любой части лога

-полностью настраиваемый формат вывода.

Конфигурационный файл rsyslog.

Демон rsyslog получает конфигурации из файла «rsyslog.conf», который находится в каталоге /etc.

В основном, файл rsyslog.conf говорит демону, где хранить сообщения. Данная информация имеет вид серии строк, состоящих из двух частей. Под двумя частями строк подразумеваются селектор и действие (selector и action). Они разделяются пробельным символом. Селектор указывает на  источник и важность сообщения, а действие говорит, что нужно сделать с данным сообщением. Сам селектор также разделен на 2 части символом точки (.). Часть перед символом точки называется объектом (источник сообщения), а часть за символом называется приоритетом (степень важности сообщения). Комбинация объекта-приоритета и действия говорит rsyslog, что делать, если сообщение соответствует указанным параметрам.

Вот отрывок из файла rsyslog.conf на CentOS:

# rsyslog v5 configuration file

...

# Include all config files in /etc/rsyslog.d/

IncludeConfig /etc/rsyslog.d/*.conf

#### RULES ####

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

#kern.*  /dev/console

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.

authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.

mail.*                                                  -/var/log/maillog

# Log cron stuff

cron.*                                                  /var/log/cron

# Everybody gets emergency messages

*.emerg                                                 *

# Save news errors of level crit and higher in a special file.

uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log

local7.*                                                /var/log/boot.log

...

Читаем журналы Linux #3.

Всем привет.

Показывая Как читать журналы также необходимо сказать Что именно читать. Поэтому сказав вчера "А" сегодня скажу "Б", т.е. продолжу серию заметок про журналы Linux.

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

Стандартные журналы.

По умолчанию журналы в Linux хранятся в  /var/log.

Для просмотра списка журналов, находящихся в данном каталоге, используйте команду ls -l /var/log.

Примеры журналов:

/var/log/syslog или /var/log/messages - глобальный системный журнал

/var/log/auth.log или /var/log/secure - информация об авторизации пользователей

/var/log/dmesg - оборудование и драйверы устройств

/var/log/anaconda.log - лог установки системы

/var/log/audit - лог демона auditd

/var/log/boot.log - лог загрузки системы

/var/log/cron - лог демона crond

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

/var/log/yum.log — для программ установленных с помощью yum в RedHat

/var/log/emerge.log — для ebuild-ов установленных из Portage с помощью emerge в Gentoo

/var/log/dpkg.log — для программ установленных с помощью dpkg в Debian и всем семействе родственных дистрибутивов

/var/log/mysql - логи базы данных MySQL

/var/log/apache2 - логи веб-сервера Apache

/var/log/nginx - логи веб-сервера NGINX

root@logs ~]# dmesg -l err

[1131424.604352] logs kernel: end_request: I/O error, dev sdc, sector 

[1131424.604352] logs kernel: Buffer I/O error on device sdc, logical 

[1131424.604352] logs kernel: Buffer I/O error on device sdc, logical 

Ускоряем Ansible #4.

Всем привет.

Финальная часть по ускорению сценариев Ansible.

#4 Параллелизм.

Для каждой задачи Ansible устанавливает соединения параллельно с несколькими хостами и запускает на них одну и ту же задачу параллельно. Однако Ansible необязательно будет устанавливать соединения сразу со всеми хостами -уровень параллелизма контролируется параметром по умолчанию, равным 5. Изменить его можно одним из двух способов. Можно настроить переменную среды ANSIBLE_FORKS, как это показано в примере 11.

Пример 11 Настройка ANSIBLE_FORKS

$ export ANSIBLE_FORKS=20

$ ansible-playbook playbook.yml

Можно также изменить настройки в файле конфигурации Ansible (ansible.cfg), определив параметр forks в секции default, как показано в примере 12.

Пример 12 ansible.cfg. Настройка параллелизма

[defaults]

forks = 26

Ускоряем Ansible #3.

Всем привет.

Ну что, продолжим разгон?

#3 Кэширование фактов.

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

- name: an example play that doesn't need facts 

  hosts: myhosts

  gather_facts: False 

  tasks:

# здесь находятся сами задачи

Также можно отключить сбор фактов по умолчанию, добавив в файл ansible.cfg:

[defaults]

gathering = explicit

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

В примере 7 приводятся строки, которые необходимо добавить в файл ansible.cfg для включения кэширования фактов. Значение fact_caching_tineout выражается в секундах, в примере используется тайм-аут, равный 24 часам (86 400 секундам). Как это всегда бывает с решениями, использующими кэширование, существует опасность, что кэшированные данные станут неактуальными. Некоторые факты, такие как архитектура CPU (факт ansible_architecture), редко изменяются. Другие, такие как дата и время, сообщаемые машиной (факт ansible_date_tine), гарантированно изменяются очень часто. Если вы решили включить кэширование фактов, убедитесь, что знаете, как часто изменяются факты, используемые вашим сценарием, и задайте соответствующее значение тайм-аута кэширования. Чтобы очистить кэш до запуска сценария, передайте параметр --flush-cache утилите ansible-playbook.

Скрипт очистки базы WSUS.

Всем привет.

Собственно я не планировал возвращаться к теме WSUS, так как я уже писал про него. Но на днях надо было оживлять WSUS-сервер у коллег. И главной проблемой там стало почти полное отсутствие свободного места на диске. Мой интерес к ситуации подогрелся тем что  на сервере был найден скрипт WsusCleanup.ps1 который, по непонятным причинам, не использовался.

Что он может сделать? Собственно WsusCleanup.ps1 это Powershell-скрипт очистки базы WSUS от некой фирмы "Экспресс АйТи, 2012".

Справка его гласит:

WsusCleanup.ps1 [Server] [Port] [/SSL] [/SkipGroups [group1][, group2]...]

Server -  имя WSUS. По умолчанию localhost

Port -   порт WSUS. По умолчанию 80 (443, если указан ключ /SSL)

/SSL -  использовать защищённое (SSL) соединение

/SkipGroups [group1][, group2]...  - имена групп компьютеров на WSUS, состояние установки которых не влияет на выбор заменённых обновлений.

Примеры:

WsusCleanup.ps1

WsusCleanup.ps1 Server01

WsusCleanup.ps1 Server01 1000 /SSL

WsusCleanup.ps1 Server01 /SkipGroups `"Unassigned Computers`", Deprecated

$commandLineHelp = "Наберите WsusCleanup.ps1 /? для помощи."

Не хотите его искать? Ложу его сюда, вдруг вам пригодиться. Мне пригодился, плюс еще понадобилось перегрузить web-пул самого WSUS. На будущее целесообразно включить выполнение этого скрипта на сервере по расписанию.

Успехов.

Ускоряем Ansible #2.

Всем привет.

Продолжим наши гонки с Ansible. Рассмотрим конвейерный режим выполнения задач.

#2 Конвейерный режим.

Вспомним, как Ansible выполняет задачу:

1.Генерирует сценарий на Python, основанный на вызываемом модуле.

2.Копирует его на хост.

3.И запускает его там.

Ansible поддерживает прием оптимизации - конвейерный режим, - объединяя открытие сеанса SSH с запуском сценария на Python. Экономия достигается за счет того, что в этом случае требуется открыть только один сеанс SSH вместо двух. По умолчанию конвейерный режим не используется, потому что требует настройки удаленных хостов, но мне нравится использовать его, поскольку он ускоряет процесс. Чтобы включить этот режим, внесите изменения в файл ansible.cfg, как показано в примере 3.

Пример 3 ansible.cfg, включение конвейерного режима

[defaults] 

pipelining = True

1) Настройка хостов для поддержки конвейерного режима

Для поддержки конвейерного режима необходимо убедиться, что на хостах в файле /etc/sudoers выключен параметр requiretty. Иначе при выполнении сценария вы будете получать ошибки, как показано в примере 4.

Nping - еще один универсальный пинглер.

Всем привет.

Я уже говорил о разных утилитах для тестирования сети, таких как iperf, hping, fping и других. Оказывается существует утилита под именем nping. Nping является частью пакета nmap и устанавливается по умолчанию. Nping имеет несколько режимов работы.

ICMP mode.

Существует несколько утилит ICMP, и большинство из них выполняют основы отправки пакета эхо-запроса, ожидания эхо-ответа и устранения задержки. Разумеется Nping включает эту функцию, как показано ниже.

admin1@admin1-VirtualBox$ sudo nping --icmp -c 2 google.com

Starting Nping 0.7.40 ( https://nmap.org/nping ) at 2020-08-31 22:21 PDT

SENT (0.0794s) ICMP [172.31.0.69 > 1.1.1.1 Echo request (type=8/code=0) id=63051 seq=1] IP [ttl=64 id=16703 iplen=28 ]

RCVD (0.2469s) ICMP [1.1.1.1 > 172.31.0.69 Echo reply (type=0/code=0) id=63051 seq=1] IP [ttl=55 id=62721 iplen=28 ]

SENT (1.0800s) ICMP [172.31.0.69 > 1.1.1.1 Echo request (type=8/code=0) id=63051 seq=2] IP [ttl=64 id=16703 iplen=28 ]

RCVD (1.2969s) ICMP [1.1.1.1 > 172.31.0.69 Echo reply (type=0/code=0) id=63051 seq=2] IP [ttl=55 id=39803 iplen=28 ]

Max rtt: 216.656ms | Min rtt: 167.355ms | Avg rtt: 192.005ms

Raw packets sent: 2 (56B) | Rcvd: 2 (92B) | Lost: 0 (0.00%)

Nping done: 1 IP address pinged in 1.44 seconds

Опция -c говорит nping посылать 2 пакета вместо 5 по умолчанию.

Смена стандартного порта SSH-сервера.

Всем привет.

По умолчанию SSH-сервер открывает для входящих соединений 22 TCP-порт, и тем самым вызывает потенциальную угрозу bruteforce-атак, поскольку злоумышленник обнаружив на сервере такой открытый порт, пытается подобрать пароль к удалённому серверу при помощи специальных средств.

Особо отметим, что не стоит воспринимать смену стандартного порта SSH-сервера как панацею. Китайская мудрость гласит - «Security by Obscurity is no Security at all». Не забывайте и про другие методы защиты SSH, такие как правильная настройка межсетевого экрана, разрешение доступа только ограниченному набору IP-адресов, отказ от парольной аутентификации и использование ключей RSA/DSA, и т.п.

Конфигурация SSH-сервера обычно располагается в /etc/ssh/sshd_config. Для редактирования этого файла вам потребуются привилегии суперпользователя root, или возможность выполнить sudo для получения таких привилегий текстовым редактором.

Выполним команду:

sudo nano /etc/ssh/sshd_config

В открывшемся файле найдите следующую строку:

Port 22

Закомментируйте её и добавьте новую строку со случайным номером порта, например 58291. Номер порта не должен превышать 65535. Также удостоверьтесь, что выбранное вами значение не конфликтует с другими сервисами в системе, например mysqld использует порт 3306, httpd - 80, ftpd - 21. Рекомендуем выбрать пятизначное значение. На всякий случай, для просмотра уже открытых в системе портов, выполните следующую команду:

netstat -tupln | grep LISTEN

Инсталлируем софт с помощью Ansible #3.

Всем привет.

Продолжим тему инсталлирования софта с помощью Ansible в Linux. Представим задачу что у нас есть сервер mysql который привязан на адрес 127.0.0.1. А мы хотим дать к нему доступ для всех. Т.е. имеем: [mysqld] bind-address  = 127.0.0.1. А хотим указать как: [mysqld] bind-address = 0.0.0.0.

1) Пишем  наш плейбук:

---

- name: Reconfigure MariaDB Server to listen for external connections

  lineinfile:

    path: /etc/mysql/mariadb.conf.d/50-server.cnf

    regexp: '^bind-address\s+='

    line: 'bind-address = 0.0.0.0'

    insertafter: '^\[mysqld\]'

    state: present

- name: Restart MariaDB to pick up configuration changes

  service:

    name: mariadb

    state: restarted

Давайте задачу lineinfile рассмотрим более подробно:

-path: Сообщает своему модулю какой файл настроек изменять.

-regexp: Применяется для определения имеющейся изменяемой строки, когда она присутствует, чтобы у нас не было двух конфликтующих директив bind-address.

-line: Значение строки для замены/ вставки в изменяемый файл настроек.

-insertafter: Когда не найдено соответствие regexp (то есть данная строка не представлена в изменяемом файле), данная директива обеспечит вставку модулем lineinfile некой новой строки после имеющегося оператора [mysqld], тем самым обеспечивая его наличие в верной части данного файла.

-state: Установка в значение present обеспечивает что данная строка присутствует в изменяемом файле, даже когда нет первоначального совпадения regexp - в такой ситуации в изменяемый файл добавляется некая строка в соответствии со значением line.

OneDrive и его Корзина.

Всем привет.

Есть в корпоративном OneDrive одна фишка. Называется она "Корзина". Она не влияет на ваше настроение до тех пор пока вы не ограничены лимитом на размещение файлов в гигабайтах. 

И вот вы достигли потолка. И вы начинаете, возмущаясь про себя на все облака в мире, судорожно чистить свой OneDrive. Разумеется, весь выделенный вашей рукой мусор летит в Корзину. И этот мусор продолжает учитываться в вашем лимите. Ужас, вы набираете воздуха поглубже и выбираете операцию "Очистить корзину". Вот этот миг, Корзина чиста, но лимит по-прежнему полон. В чем дело?! Вы негодуете...

А дело в том, что OneDrive имеет две корзины - 1-го уровня и 2-го.  По умолчанию все что вы удаляете попадает в Корзину №1. Если вы очищаете ее, то это все перетекает в Корзину №2. И только удаление из 2-й корзины удаляет файлы навсегда и освобождает ваш лимит. Автоматом файлы хранятся в обоих корзинах по 30 дней до (переноса)удаления. Это период может менять администратор, не пользователь.

Увидимся.

Ускоряем Ansible #1.

Всем привет.

Рано или поздно возникает потребность в ускорении выполнения сценариев Ansible. 

Для реализации этого есть несколько путей:

-мультиплексирование SSН, 

-конвейерный режим, 

-кэширование фактов, 

-параллельное выполнения задач, 

-асинхронное выполнения задач.

Рассмотрим их подробнее. В подготовке статьи использовались материалы из книги "Запускаем Ansible" авторов Мозер Р. и Хоштейн Л., 2018.

#1 Мультиплексирование SSH и ControlPersist.

Вы знаете, что в качестве основного транспортного механизма Ansible использует протокол SSH. Поскольку протокол SSH работает поверх протокола TCP, вам потребуется установить новое TCP-соединение с удаленной машиной. Клиент и сервер должны выполнить начальную процедуру установки соединения, прежде чем начать выполнять какие-то фактические действия. Эта процедура занимает некоторое время, хоть и небольшое. Во время выполнения сценариев Ansible устанавливает достаточно много SSH-соединений, например для копирования файлов или выполнения команд. Каждый раз Ansible устанавливает новое SSH-соединение с хостом.

OpenSSH - наиболее распространенная реализация SSH и SSH-клиент по умолчанию, который установлен на вашей локальной машине, если вы работаете в Linux или Mac OS X. OpenSSH поддерживает вид оптимизации с названием мультиплексирование каналов SSH, который также называют ControlPersist. Когда используется мультиплексирование, несколько SSH-сеансов с одним и тем же хостом использует одно и то же TCP-соединение, то есть ТСР­-соединение устанавливается лишь однажды.

Когда активируется мультиплексирование:

- при первом подключении к хосту OpenSSH устанавливает основное соединение;

- OpenSSH создает сокет домена Unix (управляющий сокет), связанный с удаленным хостом;

- при следующем подключении к хосту вместо нового ТСР­-подключения OpenSSH использует контрольный сокет.

Основное соединение остается открытым в течение заданного пользователем интервала времени, а затем закрывается SSH-клиентом. По умолчанию Ansible устанавливает интервал, равный 60 секундам.

Zabbix performance tuning #3.

Всем привет.

Оптимизация Zabbix-а опять на повестке дня. Я вам, наверное, с этим уже надоел. Но сегодня мы, наконец-то, добрались до реального случая. Я кратко покажу что мы меняли на своем сервере, за исключением параметров для базы данных. В разделе БД мнения разделились поэтому ниже опишу только то, что нам предлагали, но что так мы не успели оценить практически. Поехали.

Для беглого мониторинга средствами Zabbix был собран вот такой вот полигон.

Как же мы оценивали "здоровье" нашего Zabbix-сервера?

Этап 1.
По штатным графикам:
Zabbix data gathering process busy %
Zabbix internal process busy %

а также по
Zabbix internal queues
Zabbix server performance

оцениваем максимальные значения загруженности Zabbix-a.

Чтобы уменьшить эти величины меняем дефолтные в
#sudo nano /etc/zabbix/zabbix_server.conf
на

StartPollers=50
StartPreproceessors = 60
StartPollersUnreachable=30
StartPingers=100
StartIPMIPollers=10
StartTrappers=20
StartDBSyncers=8

Не забываем передернуть службу zabbix-server:
#sudo service zabbix-server restart
Опять оцениваем результат по тем же графикам.