Centos 8 установка и настройка

Установка и настройка Winlogbeat

Для настройки централизованного сервера сбора логов с Windows серверов, установим сборщика системных логов winlogbeat. Для этого скачаем его и установим в качестве службы. Идем на страницу загрузок и скачиваем msi версию под вашу архитектуру — 32 или 64 бита.

Запускаем инсталлятор и в конце выбираем открытие директории по умолчанию.

Создаем и правим конфигурационный файл winlogbeat.yml. Я его привел к такому виду:

winlogbeat.event_logs:
  - name: Application
    ignore_older: 72h
  - name: Security
  - name: System

tags: 

output.logstash:
  hosts: 

logging.level: info
logging.to_files: true
logging.files:
  path: C:/ProgramData/Elastic/Beats/winlogbeat
  name: winlogbeat.log
  keepfiles: 7

xpack.monitoring:
  enabled: true
  elasticsearch:
    hosts: ["http://10.1.4.114:9200"]

В принципе, по тексту все понятно. Я беру 3 системных лога Application, Security, System (для русской версии используются такие же названия) и отправляю их на сервер с logstash. Настраиваю хранение логов и включаю мониторинг по аналогии с filebeat

Отдельно обращаю внимание на tags: . Этим тэгом я помечаю все отправляемые сообщения, чтобы потом их обработать в logstash и отправить в elasticsearch с отдельным индексом

Я не смог использовать поле type, по аналогии с filebeat, потому что в winlogbeat в поле type жестко прописано wineventlog и изменить его нельзя. Если у вас данные со всех серверов будут идти в один индекс, то можно tag не добавлять, а использовать указанное поле type для сортировки. Если же вы данные с разных среверов хотите помещать в разные индексы, то разделяйте их тэгами.

Для того, чтобы логи виндовых журналов пошли в elasticsearch не в одну кучу вместе с nginx логами, нам надо настроить для них отдельный индекс в logstash в разделе output. Идем на сервер с logstash и правим конфиг output.conf.

output {
    if  == "nginx_access" {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "nginx-%{+YYYY.MM.dd}"
        }
    }
    else if  == "nginx_error" {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "nginx-%{+YYYY.MM.dd}"
        }
    }
    else if "winsrv" in  {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "winsrv-%{+YYYY.MM.dd}"
        }
    }
    else {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "unknown_messages"
        }
    }
	#stdout { codec => rubydebug }
}

Думаю, по тексту понятен смысл. Я разделил по разным индексам логи nginx, системные логи виндовых серверов и добавил отдельный индекс unknown_messages, в который будет попадать все то, что не попало в предыдущие. Это просто задел на будущее, когда конфигурация будет более сложная, можно будет ловить сообщения, которые по какой-то причине не попали ни в одно из приведенных выше правил. Я не смог в одно правило поместить оба типа nginx_error и nginx_access, потому что не понял сходу, как это правильно записать, а по документации уже устал лазить, выискивать информацию. Так получился рабочий вариант.

После этого перезапустил logstash и пошел на windows сервер, запустил службу Elastic Winlogbeat 7.11.0.

Подождал немного, пока появятся новые логи на виндовом сервере, зашел в kibana и добавил новые индексы. Напомню, что делается это в разделе Stack Management ->  -> Index Patterns.

Добавляем новый индекс по маске winsrv-*.

Можно идти в раздел Discover и просматривать логи с Windows серверов.

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

На этом я закончил настройку ELK стека из Elasticsearch, Logstash, Kibana, Filebeat и Winlogbeat. Описал основной функционал по сбору логов. Дальше с ними уже можно работать по ситуации — строить графики, отчеты, собирать дашборды и т.д. В отдельном разделе ELK Stack у меня много примеров на этот счет.

Типы iso образов CentOS 7

Релиз CentOS содержал в себе несколько видов iso образов. Подробное описание каждого из них представлено в таблице:

CentOS-7-x86_64-DVD Этот DVD образ содержит все пакеты, которые могут быть установлены с помощью инсталлера. Рекомендуется для большинства пользователей.
CentOS-7-x86_64-NetInstall Этот NetInstall образ для установки по сети и для восстановления. Инсталлятор спросит, откуда будет производиться установка пакетов. Удобно использовать, если у вас есть локальный репозиторий пакетов.
CentOS-7-x86_64-Everything В этом Everything образе содержится полный набор пакетов CentOS 7. Он может быть использован для установки, либо обновления локального зеркала. Для этого образа требуется двухсторонний DVD, либо флешка на 8 Гб.
CentOS-7-x86_64-LiveGNOME CentOS-7-x86_64-LiveKDE Эти два образа являются LiveCD CenOS 7. В зависимости от названия используется та или иная графическая оболочка. Они разработаны для тестирования окружения CentOS 7. Они не устанавливаются на жесткий диск, если вы не собираетесь этого делать принудительно. Набор установленного программного обеспечения поменять нельзя, это можно сделать только на установленной операционной системе с помощью yum.
CentOS-7-x86_64-Minimal С помощью этого Minimal образа можно установить базовую систему CentOS с минимальным набором пакетов, необходимых для работоспособности системы. Все остальное можно доустановить позже с помощью yum. Набор пакетов в этом образе будет такой же, как и на DVD при выборе установки minimal.

Я обычно использую для установки либо minimal образ, либо netinstall.

Что нового

Рассмотрим основные изменения, которые влияют на процесс настройки операционной системы и работы с ней.

1. Установка пакетов

Пакетный менеджер.

Пакетный менеджер YUM заменен на DNF. Последний потребляем меньше ресурсов и работает быстрее. Синтаксис установки пакетов, во многом, остается таким же, например:

dnf install bind

Однако, команда yum install bind также отработает — yum является алиасом для dnf, поэтому привычный формат установка пакетов и обновлений сохранен.

Репозитории.

Для установки и обновления пакетов используются базовый репозиторий и BaseOS и модульный AppStream. Базовый содержит минимально необходимый для работы набор пакетов, AppStream — все остальное. Более того, AppStream может использоваться в двух форматах — классическом RPM и модульном.

Модульный репозиторий содержит наборы с альтернативными версиями пакетов — таким образом можно установить программное обеспечение либо основной версии (которая по умолчанию поддерживается релизом CentOS), либо альтернативную (она тоже официально поддерживается операционной системой). Набор пакетов в модульном репозитории представляет из себя логическую единицу для установки приложения — само приложение, набор библиотек и инструментов для его работы. Все наборы тестируются перед размещением в репозиторий.

2. Сетевые настройки

Управление сетью.

Для управления сетью используется только NetworkManager. Скрипты ifup и ifdown объявлены как устаревшие. Для перезапуска сети теперь используется команда:

systemctl restart NetworkManager

* раньше это можно было сделать командой systemctl restart network.

Брандмауэр.

Пакетный фильтр nftables пришел на смену старому доброму iptables. firewalld переведён на использование nftables. Также появились утилиты iptables-translate и ip6tables-translate для конвертации старых правил под iptables.

TCP/IP.

TCP стек обновлен до версии 4.16. Разработчики отмечают увеличение скорости при обработке входящих соединений.

3. Установка

Инсталлятор.

Добавлена возможность установки системы на накопители NVDIMM. Инструмент Image Builder позволяет пользователям создавать настраиваемые системные образы в различных форматах, включая изображения, подготовленные для развертывания в облаках различных поставщиков.

4. Безопасность

Политики настройки криптографических подсистем.

Пакет OpenSSL обновлен до версии 1.1.1 с поддержкой TLS 1.3. Это позволит не пересобирать некоторые пакеты (например nginx для включения http/2).

Также с помощью команды update-crypto-policies можно выбрать один из режимов выбора криптоалгоритмов.

PKCS#11.

Включена поддержка смарткарт и HSM c токенами PKCS#11;

5. Виртуальзация

QEMU.

QEMU обновлен до версии 2.12. Виртуальные машины создаются с поддержкой PCI Express и с эмуляцией чипсета ICH9. Реализован режим sandbox-изоляции для ограничения системных вызовов.

Утилита virt-manager является устаревшей и вместо нее рекомендуется использовать веб-интерфейс Cockpit.

6. Веб-разработка

Языки программирования.

По умолчанию из репозитория теперь устанавливаются:

  • php7.2 вместо php5.4
  • Python 3.6 вместо 2.7
  • Ruby 2.5
  • Perl 5.26
  • SWIG 3.0

Базы данных.

Также из коробки будут устанавливаться:

  • MariaDB 10.3
  • MySQL 8.0
  • PostgreSQL 10 или PostgreSQL 9.6
  • Redis 5

Веб-серверы.

Версии устанавливаемых по умолчанию пакетов — Apache 2.4 и nginx 1.14.

7. Графический интерфейс

Desktop.

По умолчанию устанавливается графический интерфейс GNOME версии 3.28. В качестве протокола организации графического сервера используется Wayland. По сравнению с Xorg, Wayland задействует меньше программных и аппаратных ресурсов и считается, что работает быстрее. Однако, использование Xorg в CentOS 8 также возможно.

Пакеты KDE удалены из состава дистрибутива.

Cockpit.

Cockpit — веб-интерфейс для управления CentOS. Он может оказаться полезным новичкам. Для его запуска нужно выполнить несколько несложных команд.

Установка:

dnf install cockpit

Настройка брандмауэра:

firewall-cmd —permanent —add-port=9090/tcp

firewall-cmd —reload

Запуск:

systemctl enable —now cockpit.socket

systemctl start cockpit

Можно заходить на интерфейс по адресу https://<IP-адрес компьютера>:9090/. В качестве логина используем системную учетную запись, например, root.

Весь список изменений можно найти на сайте Red Hat.

Обычное обновление CentOS

На производственных серверах перед обновлением рекомендуется выполнить полное резервное копирование системы чтобы в случае непредвиденной ситуации иметь возможность все быстро восстановить. Сделайте резервную копию директорий /etc, /var, /opt. Для систем, запущенных в виртуальных окружениях желательно сделать снапшот. Дальше выполните такую команду для обновления:

Далее вам необходимо подтвердить обновление, для этого ознакомьтесь со списком пакетов и нажмите «y»:

Утилита yum имеет опцию -y, которая указывает, что вы автоматически согласны с изменениями, но ее использовать не рекомендуется. После завершения обновления необходимо перезагрузить сервер:

Теперь можно снова посмотреть версию:

Как видите, мы очень просто обновились до нового релиза CentOS 7.4 без каких-либо дополнительных настроек и команд. Это очень просто.

Установка ядра

Перед обновлением ядра, необходимо обновить саму систему:

yum update

После стоит перезагрузить систему:

shutdown -r now

Далее у нас на выбор два способа обновления ядра — с использованием репозитория или вручную, скачав исходник с kernel.org.

С помощью yum

Самый быстрый и безопасный способ обновить ядро CentOS — воспользоваться автоматической установкой из репозитория. Минусом тут является то, что можно установить только ту версию, которая имеется в наличие в данном репозитории.

Последняя версии ядра для CentOS находится в репозитории ELRepo (не путать с EPEL). Сначала устанавливаем его.

Переходим на веб-страницу elrepo.org и копируем ссылку на последнюю версию репозитория для нашей версии операционной системы, например:

Импортируем ключ репозитория:

rpm —import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

Воспользовавшись ссылкой, устанавливаем сам репозиторий:

yum install https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

* список установленных репозиториев можно посмотреть командой yum repolist.

Теперь можно установить ядро:

yum —enablerepo=elrepo-kernel install kernel-ml

Ручное обновление

Чаще всего, администратор пользуется встроенными в сборку Linux инструментами (как описано выше) — это безопаснее и проще. Однако, если нужной версии ядра нет в репозитории или мы хотим установить тестовую версию, необходима ручная установка.

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

Для начала переходим на сайт kernel.org и копируем ссылку на нужную версию ядра Linux:

* в данном примере мы скопировали ссылку на нестабильную версию ядра 5.0.

Воспользовавшись ссылкой, скачиваем ядро на компьютер с Linux:

wget https://git.kernel.org/torvalds/t/linux-5.0-rc8.tar.gz

* если система вернет ошибку, нужно установить wget — yum install wget.

Распаковываем скачанный архив:

tar -xvf linux-5.0-rc8.tar.gz -C /usr/src

* в данном примере мы распаковываем архив linux-5.0-rc8.tar.gz в каталог /usr/src.

Переходим в каталог, куда распаковали исходник ядра:

cd /usr/src/linux-5.0-rc8/

Устанавливаем инструменты для компиляции пакетов:

yum groupinstall «Development Tools»

yum install ncurses-devel openssl-devel bc

Создаем свою конфигурацию для ядра:

make menuconfig

Или используем текущую конфигурацию для ядра:

make oldconfig

На все вопросы, которые задает система можно отвечать нажатием Enter, чтобы принимать значения по умолчанию.

Компилируем ядро:

make

* процедура может занять много времени.

После устанавливаем ядро и модули:

make modules_install install

Обновление phpmyadmin

Для начала напомню, как в vestacp зайти в phpmyadmin. Я не сразу нашел соответствующую ссылку. Она в разделе DB.

Конфигурационный файл находится на сервере по адресу /etc/phpmyadmin/config.inc.php. Vesta использует в своей работе обычную версию phpmyadmin, которую можно установить из подключенных репозиториев в системе.

Таким образом, для обновления phpmyadmin в vestacp достаточно воспользоваться стандартным пакетным менеджером в системе (apt, yum и т.д.) и выполнить соответствующую команду по обновлению системного пакета.

Если по какой-то причине не хочется использовать репозиторий, можно просто положить свежие исходники в соответствующий каталог — /usr/share/phpMyAdmin.

Изменения 8-й версии

Пройдемся по основным нововведениям CentOS 8, которые показались интересными лично мне. Функционально это полная копия RHEL 8, поэтому все его изменения на 100% актуальны для центос. Вот список наиболее интересных изменений:

  1. Разделение основного репозитория на 2 — BaseOS и AppStream. Первый будет работать как и раньше, а второй — appstream, сделали для того, чтобы была возможность устанавливать разные версии пакетов на сервер. Этот репозиторий поддерживает новый модульный формат rpm пакетов.
  2. Переход на пакетный менеджер DNF, который поддерживает модульный формат пакетов. Прощай YUM. Теперь это просто алиас для запуска dnf.
  3. Традиционно обновился весь софт и ядро (4.18) Linux. Теперь мы какое-то время будем иметь свежий софт. Прощай php5.4 из базового репозитория :) Я не буду по тебе скучать. Здравствуй php 7.2 и Python 3.6 из коробки.
  4. Замена iptables на nftables. Тут для меня самые серьезные изменения. Iptables я активно использую и настраиваю почти на всех серверах. С nftables не знаком вообще. Надо срочно переучиваться и осваивать новый функционал. Будут статьи на эту тему. Пожалуй этому нововведению я совсем не рад. Лично меня iptables устраивали целиком и полностью в первую очередь тем, что они используются почти везде. Можно брать готовый набор правил и спокойно переносить между серверами с разными ОС. Именно поэтому я всегда пользуюсь голыми iptables, а не надстройками над ними в виде firewalld или ufw. Мне достаточно знать только iptables, чтобы настроить firewall на любом linux сервере.
  5. Убрана поддержка Btrfs. Лично я ей никогда не пользовался, но я знаю, что это популярная штука и удаление ее поддержки значительное событие.
  6. До кучи обновился openssl и tls до последних версий 1.1.1 и 1.3. Некоторое время назад приходилось отдельно собирать пакеты для использования свежих версий. Теперь это на некоторое время ушло в прошлое, пока текущий релиз CentOS 8 не устареет. Года 2-3 будем жить спокойно.
  7. Network scripts для настройки сети объявлены устаревшими и по дефолту не поддерживаются. Можно поставить отдельно пакет для их работы. Для настройки сети надо использовать исключительно NetworkManager, который лично я предпочитаю отключать сразу после установки сервера. Не знаю, чем network-scripts не угодили. Простой и удобный инструмент.

Более подробно с изменениями 8-й версии можете познакомиться на opennet или почитать полный список в оригинале на сайте redhat. Я полистал последний. Там в overview есть ссылки на подробное описание по каждому компоненту системы.

Общая настройка vesta cp

Сразу после установки можно выполнить несколько базовых настроек.

Включаем русский язык

Vestacp неплохо переведена на русский язык, поэтому можно смело пользоваться русским интерфейсом. Для его выбора, необходимо зайти в настройки пользователя и там указать язык.

Добавляем ip адрес

У меня на сервере 2 внешних ip адреса. Во время установки панели, был выбран только один. Добавлю сейчас второй. Для этого в верхнем меню выбираем IP, нажимаем на зеленый плюс и вводим настройки дополнительного ip.

Теперь при добавлении сайта можно будет выбирать, на каком ip адресе он будет работать.

Отключаем автообновления

Я не раз сталкивался с различными проблемами, которые возникают после обновлений. А в такой вещи, как бесплатная панель управления хостингом, вероятность получить проблемы из-за каких-то багов или непроверенных изменений очень велики. Я рекомендую автоматические обновления отключить, и обновлять все вручную, когда будете полностью уверены, что готовы к обновлению.

Идем в раздел обновление и жмем «Выключить автообновление»

Увеличение времени бана

В vestacp используется популярный инструмент fail2ban для блокировки тех, кто пытается подобрать логины с паролями для доступа к различным сервисам. Время бана используется по-умолчанию — 600 секунд, т.е. 10 минут. Тот, кто 5 раз ввел неверные регистрационные данные для доступа к ssh, панели управления vesta или другим сервисам, получает бан на уровне фаервола на 10 минут.

По ssh боты будут постоянно долбиться, поэтому их можно банить минимум на час. Для этого нужно открыть конфиг fail2ban и добавить туда новое значение. Идем в раздел Сервер, находим там в самом низу fail2ban и жмем configure.

В секцию  добавляем новый параметр:

bantime = 3600

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

Два: установить ядро ​​и загрузочную программу grub

1. Переключите корневой каталог диска

# choot /mnt/sysimages

2. Смонтируйте CD в / media

# mout /dev/sr0 /media

3. Установите пакет с ядром

# rpm -ivh /media/Packages/kernel-2.6.32-696.el6.x86_64.rpm —force

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

4. Перейдите в каталог / boot и просмотрите файлы.

# cd /boot ; ls

Как видите, файл ядра восстановлен, но загрузочный файл grub все еще отсутствует

5. Установите файл grub

# grub-install  —root-directory=/ /dev/sda

—root-directory <<< Укажите родительский каталог, в котором расположен корневой каталог, то есть корневой каталог

/ dev / sda <<< Укажите, на каком устройстве устанавливать grub, поскольку наш загрузочный раздел находится в / dev / sda, все установлены в / dev / sda

# ls /boot/grub/

Видно, что файл grub в основном установлен, но grub.conf по-прежнему отсутствует. Этот файл можно импортировать с других серверов или редактировать вручную.

Вручную отредактируйте файл grub.cfg:

# vim /boot/grub/grub.conf

Примечание: root (hd0,0) <<< относится к разделу диска, на котором находится ядро, (hd0,0) представляет первый раздел диска 0, то есть / dev / sda1, (hd0,1) представляет второй раздел.

6. Выход для выхода и перезапуска системы

Заключение

Я постарался рассказать подробно и понятно о полной настройке ELK Stack. Информацию в основном почерпнул в официальной документации. Мне не попалось более ли менее подробных статей ни в рунете, ни в буржунете, хотя искал я основательно. Вроде бы такой популярный и эффективный инструмент, но статей больше чем просто дефолтная установка я почти не видел. Буквально одна на хабре попалась с какой-то более ли менее кастомизацией.

Какие-то проверенные моменты я не стал описывать в статье, так как посчитал их неудобными и не стал использовать сам. Например, если отказаться от logstash и отправлять данные с beats напрямую в elasticsearch, то на первый взгляд все становится проще. Штатные модули beats сами парсят вывод, устанавливают готовые визуализации и дашборды в Kibana. Вам остается только зайти и любоваться красотой :) Но на деле все выходит не так красиво, как хотелось бы. Кастомизация конфигурации усложняется. Изменение полей в логах приводит к более сложным настройкам по вводу этих изменений в систему. Все настройки поступающей информации переносятся на каждый beats, изменяются в конфигах отдельных агентов. Это неудобно.

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

Я не рассмотрел в своей статье такие моменты как создание визуализаций и дашбордов в Кибана, так как материал уже и так получился объемный. Я устал писать эту статью :) Смотрите остальные мои материалы по данной теме. Там есть примеры.

Так же я не рассмотрел такой момент. Logstash может принимать данные напрямую через syslog. Вы можете, к примеру, в nginx настроить отправку логов в syslog, минуя файлы и beats. Это может быть более удобно, чем описанная мной схема. Особенно это актуально для сбора логов с различных сетевых устройств, на которые невозможно поставить агента, например mikrotik. Syslog поток так же можно парсить на ходу с помощью grok. Отдельно надо рассмотреть автоочистку старых индексов в elasticsearch.

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

Все статьи раздела elk stack — https://serveradmin.ru/category/elk-stack/.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: