Появилась задача подключить к локальной сети два дополнительных удалённых офиса. Про настройку OpenVPN сервера для желающим поработать из дома или в командировке я уже рассказывал, однако перспектива выдачи каждому пользователю сети отдельного сертификата с последующей настройкой соединения меня совсем не радовала. Потому для подключения филиалов было решено пойти другим путём.
Объединять сети будем через VPN туннели по технологии L2TP/IPsec без поднятия дополнительных серверов и использования дорогостоящего оборудования, непосредственно на роутерах Mikrotik и Keenetic Ultra II. Поводом для такого объединения, помимо удобства пользователей и моей лени, послужила некорректная работа встроенного L2TP/IPsec клиента в Windows.
Как видно из схемы, пользователи в филиалах должны иметь доступ к терминальному серверу, расположенному за роутером Keenetic Ultra II. Так как на «Кинетике» уже был настроен и благополучно работал L2TP/IPsec сервер, то «Микротикам» досталась роль клиентов. Кроме того, такой вариант существенно проще в настройке, по сравнению с поднятием VPN сервера на «микротике».
Обязательное условие: адреса объединяемых сетей не должны пересекаться между собой.
Настройка L2TP VPN-сервера на роутере Keenetic
С подробностями настройки L2TP/IPsec сервера на Keenetic Ultra можно ознакомиться перейдя по этой ссылке. Там всё просто, потому не буду повторяться. В дополнение к той статье, необходимо остановиться на паре существенных моментов, без которых не возможна нормальная работа VPN туннелей:
Отключить NAT для клиентов, оно тут будет только мешать;
Снять галочку, напротив поля «Множественный вход», если она там стояла. Это позволит точно указать IP адрес, выдаваемый клиенту L2TP сервером при подключении;
Настроить статическую маршрутизацию.
Для удалённых филиалов я выбрал имена office_01 и оffice_02 и назначил им соответсенно статические адреса 172.16.2.35 и 172.16.2.35. Эти адреса, указываются в качестве шлюзов при создании статических маршрутов для сетей, расположенных за ними. У office_01 внутренняя сеть 192.168.11.0/24, office_02 — 192.168.0.0/24
Настройка Mikrotik в качестве клиента L2TP/IPsec
Настройку удаленного клиента начнём с добавления нового интерфейса L2TP Client в разделе интерфейсов. Указываем IP-адрес L2TP сервера, свои учётные данные и общий ключ шифрования IPSec.
Если вы думаете, что этого достаточно для успешной установки соединения с сервером, поднятом на Keenetic Ultra II, то глубоко заблуждаетесь, ибо настройка «микротов» это всегда боль и страдания. Складывается впечатление, что компания Mikrotik намеренно лишает себя прибыли. Я не понимаю, что мешает выпустить нормальные пошаговые руководства по настройке своих железок и стать ведущим игроком на рынке.
Далее требуется указать нужные алгоритмы шифрования SA (Security Association) в настройках IP->IPsec->Proposals и изменить значение параметра PFS Group с modp1024 на none.
Аббревиатура PFS расшифровывается как Perfect Forward Secrecy — что-то связанное со второй фазой обмена ключами в IPsec. Честно говоря, так глубоко в эту тему не вникал и если не ошибаюсь, то на устройствах от Apple данный параметр в настройках IPsec по умолчанию тоже выключен. В общем, чтобы канал до Keenetic Ultra II поднялся, значение параметра PFS Group должно быть none.
Также скорректируем и профиль шифрования по-умолчанию IP->IPsec->Profiles:
Нажимаем «Применить», и если мы всё сделали правильно, соединение должно быть установлено.
Туннель у нас поднялся. Осталась самая малость, чтобы компьютеры за роутером получили доступ в удалённую сеть 192.168.99.0/24, где находится терминальный сервер. Для этого необходимо добавить правило маскарада и новый статический маршрут.
Переходим во вкладку IP->Firewall->NAT:
На вкладке IP->Routes в качестве шлюза указываем созданный интерфейс l2tpMainOffice, а в поле Pref. Source – наш IP-адрес в виртуальной сети:
Аналогичным образом настраивается и клиент для второй сети.
timeoutэто утилита командной строки, которая запускает указанную команду и завершает ее, если она все еще выполняется по истечении заданного периода времени. Другими словами, timeoutпозволяет запустить команду с ограничением по времени. Эта timeoutкоманда является частью пакета основных утилит GNU, который установлен практически в любом дистрибутиве Linux.
Это удобно, когда вы хотите запустить команду, которая не имеет встроенной опции тайм-аута.
В этой статье мы объясним, как использовать команду Linux timeout.
Как использовать timeoutкоманду
Синтаксис timeoutкоманды следующий:
timeout [OPTIONS] DURATION COMMAND [ARG]…
Копировать
Может DURATIONбыть положительным целым числом или числом с плавающей запятой, за которым следует необязательный суффикс единицы измерения:
s— секунды (по умолчанию)
m— минут
h— часы
d— дней
Когда единицы измерения не используются, по умолчанию используются секунды. Если для длительности установлено нулевое значение, соответствующий тайм-аут отключен.
Параметры команды должны быть указаны перед аргументами.
Вот несколько основных примеров, демонстрирующих использование timeoutкоманды:
Завершить команду через пять секунд:timeout 5 ping 8.8.8.8Копировать
Завершить команду через пять минут:timeout 5m ping 8.8.8.8Копировать
Завершить команду через одну минуту и шесть секунд:timeout 1.1m ping 8.8.8.8Копировать
Если вы хотите запустить команду, требующую повышенных привилегий, например tcpdump , добавьте sudo перед timeout:
sudo timeout 300 tcpdump -n -w data.pcap
Отправка определенного сигнала
Если сигнал не подан, timeoutотправляет SIGTERMсигнал управляемой команде, когда достигается лимит времени. Вы можете указать, какой сигнал отправлять, используя опцию -s( ).--signal
Например, чтобы отправить SIGKILLкоманду ping через одну минуту, вы должны использовать:
sudo timeout -s SIGKILL ping 8.8.8.8
Вы можете указать сигнал по имени, например SIGKILL, или по его номеру, например 9. Следующая команда идентична предыдущей:
sudo timeout -s 9 ping 8.8.8.8
Чтобы получить список всех доступных сигналов, используйте kill -l команду:
kill -l
Уничтожение зависших процессов
SIGTERM, сигнал по умолчанию, отправляемый при превышении лимита времени, может быть перехвачен или проигнорирован некоторыми процессами. В таких ситуациях процесс продолжает выполняться после отправки сигнала завершения.
Чтобы убедиться, что отслеживаемая команда уничтожена, используйте параметр -k( --kill-after), за которым следует период времени. Когда эта опция используется после достижения заданного срока, timeoutкоманда отправляет SIGKILLуправляемой программе сигнал, который нельзя перехватить или проигнорировать.
В следующем примере timeoutкоманда выполняется в течение одной минуты, и если она не будет завершена, она будет уничтожена через десять секунд:
sudo timeout -k 10 1m ping 8.8.8.8
тайм-аут -k «./test.sh»
убит после достижения заданного срока
Сохранение статуса выхода
timeoutвозвращается 124, когда лимит времени достигнут. В противном случае он возвращает статус выхода управляемой команды.
Чтобы вернуть статус выхода команды даже при достижении лимита времени, используйте --preserve-statusопцию:
timeout --preserve-status 5 ping 8.8.8.8
Бег на переднем плане
По умолчанию timeoutзапускает управляемую команду в фоновом режиме. Если вы хотите запустить команду на переднем плане, используйте --foregroundопцию:
timeout --foreground 5m ./script.sh
Этот параметр полезен, когда вы хотите запустить интерактивную команду, требующую ввода данных пользователем.
Вывод
Команда timeoutиспользуется для запуска данной команды с ограничением по времени.
timeoutэто простая команда, которая не имеет большого количества опций. Обычно вы будете вызывать timeoutтолько с двумя аргументами: продолжительностью и управляемой командой.
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
В данной инструкции рассмотрены варианты и примеры создания резервных копий и восстановления баз СУБД PostgreSQL.
Все команды, которые приводятся ниже, должны выполняться из командной строки. В Linux — это окно терминала, в Windows — командная строка (cmd.exe) с переходом в папку установки PostgreSQL.
Создание резервных копий
Базовая команда
Синтаксис:
pg_dump <параметры> <имя базы> > <файл, куда сохранить дамп>
Пример:
pg_dump users > /tmp/users.dump
Пользователь и пароль
Если резервная копия выполняется не от учетной записи postgres, необходимо добавить опцию -U с указанием пользователя:
pg_dump -U dmosk -W users > /tmp/users.dump
* где dmosk — имя учетной записи; опция W потребует ввода пароля.
Сжатие данных
Для экономии дискового пространства или более быстрой передачи по сети можно сжать наш архив:
pg_dump users | gzip > users.dump.gz
Скрипт для автоматического резервного копирования
Рассмотрим 2 варианта написания скрипта для резервирования баз PostgreSQL. Первый вариант — запуск скрипта от пользователя root для резервирования одной базы. Второй — запуск от пользователя postgres для резервирования всех баз, созданных в СУБД.
Для начала, создадим каталог, в котором разместим скрипт, например:
mkdir /scripts
И сам скрипт:
vi /scripts/postgresql_dump.sh
Вариант 1. Запуск от пользователя root; одна база.
* где password — пароль для подключения к postgresql; /backup — каталог, в котором будут храниться резервные копии; dbuser — имя учетной записи для подключения к БУБД; pathB — путь до каталога, где будут храниться резервные копии. * данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После при помощи утилиты pg_dump будет выполнено подключение и резервирование базы db. Пароль экспортируется в системную переменную на момент выполнения задачи.
Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:
crontab -e
3 0 * * * /scripts/postgresql_dump.sh
* наш скрипт будет запускаться каждый день в 03:00.
Вариант 2. Запуск от пользователя postgres; все базы.
#!/bin/bash
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
pathB=/backup/postgres
find $pathB ( -name "*-1[^5].*" -o -name "*-[023]?.*" ) -ctime +61 -delete
for dbname in `echo "SELECT datname FROM pg_database;" | psql | tail -n +3 | head -n -2 | egrep -v 'template0|template1|postgres'`; do
pg_dump $dbname | gzip > $pathB/$dbname-$(date "+%Y-%m-%d").sql.gz
done;
* где /backup — каталог, в котором будут храниться резервные копии; pathB — путь до каталога, где будут храниться резервные копии. * данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После найдет все созданные в СУБД базы, кроме служебных и при помощи утилиты pg_dump будет выполнено резервирование каждой найденной базы. Пароль нам не нужен, так как по умолчанию, пользователь postgres имеет возможность подключаться к базе без пароля.
Необходимо убедиться, что у пользователя postgre будет разрешение на запись в каталог назначения, в нашем примере, /backup/postgres.
Зададим в качестве владельца файла, пользователя postgres:
* где public — схема; students — таблица; users — база данных.
Размещение каждой таблицы в отдельный файл
Также называется резервированием в каталог. Данный способ удобен при больших размерах базы или необходимости восстанавливать отдельные таблицы. Выполняется с ипользованием ключа -d:
pg_dump -d customers > /tmp/folder
* где /tmp/folder — путь до каталога, в котором разместяться файлы дампа для каждой таблицы.
Для определенной схемы
В нашей базе может быть несколько схем. Если мы хотим сделать дамп только для определенной схемы, то используем опцию -n, например:
pg_dump -n public peoples > /tmp/peoples.public.sql
* в данном примере мы заархивируем схему public базы данных peoples.
Только схемы (структуры)
Для резервного копирования без данных (только таблицы и их структуры):
При необходимости авторизоваться при подключении к базе вводим:
psql -U dmosk -W users < /tmp/users.dump
* где dmosk — имя учетной записи; опция W потребует ввода пароля.
Из файла gz
Сначала распаковываем файл, затем запускаем восстановление:
gunzip users.dump.gz
psql users < users.dump
Или одной командой:
zcat users.dump.gz | psql users
Определенную базу
Если резервная копия делалась для определенной базы, запускаем восстановление:
psql users < /tmp/database.dump
Если делался полный дамп (всех баз), восстановить определенную можно при помощи утилиты pg_restore с параметром -d:
pg_restore -d users cluster.bak
Определенную таблицу
Если резервная копия делалась для определенной таблицы, можно просто запустить восстановление:
psql users < /tmp/students.dump
Если делался полный дамп, восстановить определенную таблицу можно при помощи утилиты pg_restore с параметром -t:
pg_restore -a -t students users.dump
С помощью pgAdmin
Запускаем pgAdmin — подключаемся к серверу — кликаем правой кнопкой мыши по базе, для которой хотим восстановить данные — выбираем Восстановить:
Выбираем наш файл с дампом:
И кликаем по Восстановить:
Использование pg_restore
Данная утилита предназначена для восстановления данных не текстового формата (в одном из примеров создания копий мы тоже делали резервную копию не текстового формата).
Из бинарника:
pg_restore -Fc users.bak
Из тарбола:
pg_restore -Ft users.tar
С созданием новой базы:
pg_restore -Ft -C users.tar
Мы можем использовать опцию d для указания подключения к конкретному серверу и базе, например:
* в данном примере мы подключимся к локальной базе (localhost) с названием dmosk_base от пользователя dmosk_user с паролем dmosk_pass.
Работа с CSV
Мы можем переносить данные с использованием файлов csv. Это нельзя назвать напрямую резервным копированием, но в рамках данной инструкции материал будет интересен.
Создание файла CSV (экспорт)
Пример запроса (выполняется в командной оболочке SQL):
> COPY (SELECT * FROM public.users WHERE name LIKE 'А%') TO '/tmp/users.csv' WITH CSV DELIMITER ';' HEADER;
* в данном примере мы выгрузим все данные для таблицы users в схеме public, где значение поля name начинается с буквы А. Результат будет сохранен в файл /tmp/users.csv. Также мы указываем, что в качестве разделителя данных нужно использовать точку с запятой и первой строкой сделать заголовок.
Также мы можем сделать выгрузку, но сделать вывод в оболочку и перенаправить его в файл:
psql -d "postgresql://pg_user:pg_pass@localhost:5432/pg_databasename" -c "COPY (SELECT * FROM public.users WHERE name LIKE 'А%') TO STDIN WITH CSV DELIMITER ';' HEADER;" > /tmp/users.csv
Импорт данных из файла CSV
Также можно выполнить запрос в оболочке SQL:
> COPY public.users FROM '/tmp/test.csv' DELIMITER ';' CSV HEADER;
* в нашем примере мы выполним импорт данных из ранее созданного файла /tmp/users.csv в таблицу users.
Возможные ошибки
Рассмотрим некоторые проблемы, с которыми можно столкнуться при работе с дампами PostgreSQL.
Input file appears to be a text format dump. please use psql.
Причина: дамп сделан в текстовом формате, поэтому нельзя использовать утилиту pg_restore.
Решение: восстановить данные можно командой psql <имя базы> < <файл с дампом> или выполнив SQL, открыв файл, скопировав его содержимое и вставив в SQL-редактор.
No matching tables were found
Причина: Таблица, для которой создается дамп не существует. Утилита pg_dump чувствительна к лишним пробелам, порядку ключей и регистру.
Решение: проверьте, что правильно написано название таблицы и нет лишних пробелов.
Too many command-line arguments
Причина: Утилита pg_dump чувствительна к лишним пробелам.
Решение: проверьте, что нет лишних пробелов.
Aborting because of server version mismatch
Причина: несовместимая версия сервера и утилиты pg_dump. Может возникнуть после обновления или при выполнении резервного копирования с удаленной консоли.
Решение: нужная версия утилиты хранится в каталоге /usr/lib/postgresql/<version>/bin/. Необходимо найти нужный каталог, если их несколько и запускать нужную версию. При отсутствии последней, установить.
No password supplied
Причина: нет системной переменной PGPASSWORD или она пустая.
Решение: либо настройте сервер для предоставление доступа без пароля в файле pg_hba.conf либо экспортируйте переменную PGPASSWORD (export PGPASSWORD или set PGPASSWORD).
Неверная команда
Причина: при выполнении восстановления возникла ошибка, которую СУБД не показывает при стандартных параметрах восстановления.
Решение: запускаем восстановление с опцией -v ON_ERROR_STOP=1, например:
psql -v ON_ERROR_STOP=1 users < /tmp/users.dump
Теперь, когда возникнет ошибка, система прекратит выполнять операцию и выведет сообщение на экран.
В последние дни многие организации стали жертвами киберпреступности. Были разработаны более сложные ботнеты и другие методы атак, которые увеличивают скорость этих атак.
Наиболее распространенными атаками являются DDoS (распределенный отказ в обслуживании), захват учетных записей (ATO) и перехват контента с веб-сайтов.
Эти атаки имеют тяжелые последствия для целевых организаций и должны быть предотвращены любой ценой.
Обычно Bad Bots можно определить как программные приложения, которые выполняют автоматизированные задачи со злыми намерениями через Интернет.
Они маскируются в системе путем маскировки агентов пользователя.
Такими плохими ботами могут быть;
Боты или серверы, связанные с вирусами или вредоносным ПО
Боты для правительственного наблюдения
Атакующие сети ботнетов (Mirai)
Сайты азартных игр и порносайты
Сканеры уязвимостей
Спам-рефереры
Браузерное рекламное и вредоносное ПО (Yontoo и т.д.)
Инструменты для исследования ссылок и тестирования обратных ссылок
SEO компании, которые используют ваши конкуренты для улучшения своего SEO
Сайты хотлинк на изображения и воры изображений
Боты для ранжирования ссылок
Сборщики электронной почты
Сайты, связанные с выгодными вредоносными программами, рекламным ПО и Ransomware Кампании Clickjacking
Остановка “Ghost спама” Google Analytics
Это руководство демонстрирует, как вы можете блокировать Bad Bots, спам, User-Agents и Ransomware на Nginx.
Шаг 1 – Скачать Nginx Bad Bot Blocker
Nginx Bad Bot Blocker был разработан Митчеллом Крогом для использования в веб-сервере Nginx.
Его можно загрузить в систему Linux с помощью команды:
### С wget
wget https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/install-ngxblocker
### С curl
sudo curl -sL https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/install-ngxblocker -o install-ngxblocker
Чтобы установить Nginx Bad Bot Blocker, мы запустим скрипт установки.
Этот скрипт можно запустить в DRY-MODE, чтобы показать изменения, которые он внесет, и файлы, которые он загрузит, как показано ниже.
sudo /usr/local/sbin/setup-ngxblocker
Вывод:
/etc/nginx/sites-available/ssl.no-default.conf
/etc/nginx/sites-available/no-default.conf
/etc/nginx/sites-available/wordpress.example.com.conf
Configure every file above as a vhost ? [Y/N] : Y
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
** Dry Run ** | not updating files | run as 'setup-ngxblocker -x' to setup files.
inserting: include /etc/nginx/conf.d/globalblacklist.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/conf.d/botblocker-nginx-settings.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/bots.d/blockbots.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
inserting: include /etc/nginx/bots.d/ddos.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
Whitelisting ip: 88.99.92.81 => /etc/nginx/bots.d/whitelist-ips.conf
Web directory not found ('/var/www'): not automatically whitelisting domains.
Checking for missing includes:
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
Nothing to update for directory: /etc/nginx/conf.d
Nothing to update for directory: /etc/nginx/bots.d
Nothing to update for directory: /usr/local/sbin
Setting mode: 700 => /usr/local/sbin/install-ngxblocker
Setting mode: 700 => /usr/local/sbin/setup-ngxblocker
Setting mode: 700 => /usr/local/sbin/update-ngxblocker
Чтобы внести изменения в nginx.conf, необходимо запустить скрипт с параметром -x.
sudo ./setup-ngxblocker -x
Ввыод:
/etc/nginx/sites-available/ssl.no-default.conf
/etc/nginx/sites-available/no-default.conf
/etc/nginx/sites-available/wordpress.example.com.conf
Configure every file above as a vhost ? [Y/N] : y
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
inserting: include /etc/nginx/conf.d/globalblacklist.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/conf.d/botblocker-nginx-settings.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/bots.d/blockbots.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
inserting: include /etc/nginx/bots.d/ddos.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
Whitelisting ip: 88.99.92.81 => /etc/nginx/bots.d/whitelist-ips.conf
Web directory not found ('/var/www'): not automatically whitelisting domains.
Checking for missing includes:
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
Nothing to update for directory: /etc/nginx/conf.d
Nothing to update for directory: /etc/nginx/bots.d
Nothing to update for directory: /usr/local/sbin
Setting mode: 700 => /usr/local/sbin/install-ngxblocker
Setting mode: 700 => /usr/local/sbin/setup-ngxblocker
Setting mode: 700 => /usr/local/sbin/update-ngxblocker
Приведенная выше команда включает все файлы виртуальных хостов Nginx на сервере и вносит ваш Ip-адрес в белый список в файле whitelist-ips.conf.
Вы можете внести желаемые изменения, отредактировав файл /etc/nginx/bots.d/whitelist-ips.conf.
По сути, скрипт добавляет приведенные ниже утверждения “include” в ваши файлы виртуальных хостов Nginx:
Кроме того, вы можете установить блокировщик в нестандартную папку Nginx, указав их:
Например, если вы хотите заблокировать доступ GoogleBot к вашему сайту, отредактируйте файл /etc/nginx/bots.d/blacklist-user-agents.conf, который отменяет белый список по умолчанию для GoogleBot.
Это можно сделать и для любого другого бота, внесенного в белый список.
Шаг 6 – Тестирование Nginx Bad Bot Blocker
Вы можете протестировать ваш Nginx Bad Bot Blocker из терминала на другой системе, используя ваше доменное имя, как показано ниже:
curl -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I http://yourdomain.com
Вы также можете использовать:
curl -A "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" -I http://yourdomain.com
Роль Graylog Ansible позволяет установить и настроить Graylog.
Ее можно установить с помощью команды:
$ ansible-galaxy install graylog2.graylog
Starting galaxy role install process
- downloading role 'graylog', owned by graylog2
- downloading role from https://github.com/Graylog2/graylog-ansible-role/archive/3.3.7.tar.gz
- extracting graylog2.graylog to /Users/jkmutai/.ansible/roles/graylog2.graylog
- graylog2.graylog (3.3.7) was installed successfully
- adding dependency: lean_delivery.java (7.1.0)
- adding dependency: elastic.elasticsearch (main)
- downloading role 'java', owned by lean_delivery
- downloading role from https://github.com/lean-delivery/ansible-role-java/archive/7.1.0.tar.gz
- extracting lean_delivery.java to /Users/jkmutai/.ansible/roles/lean_delivery.java
- lean_delivery.java (7.1.0) was installed successfully
- extracting elastic.elasticsearch to /Users/jkmutai/.ansible/roles/elastic.elasticsearch
- elastic.elasticsearch (main) was installed successfully
Из приведенного выше результата вы заметите, что следующие зависимости были установлены.
Java
Elasticsearch
Проверьте, были ли установлены зависимости роли , используя команду:
Apache Software Foundation и Apache HTTP Server Project недавно объявили о выпуске новой версии Apache HTTP Server 2.4.54, так как эта версия Apache является последней версией GA. из ветки Apache HTTPD следующего поколения 2.4.x и представляет пятнадцать лет инноваций проекта и рекомендуется по сравнению со всеми предыдущими версиями. Этот выпуск Apache представляет собой выпуск, посвященный безопасности, функциям и исправлениям ошибок.
Новая версия, котораяe представляет 19 изменений и исправляет 8 уязвимостей, из которых некоторые из них разрешали доступ к данным, также могли привести, среди прочего, к отказу в обслуживании.