По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.
SSH (Secure Shell) - это сетевой протокол, который обеспечивает безопасное удаленное соединение между двумя системами. Системные администраторы используют утилиты SSH для управления компьютерами, копирования или перемещения файлов между системами. Поскольку SSH передает данные по зашифрованным каналам, безопасность находится на высоком уровне.
Установка клиента OpenSSH
Есть много SSH-клиентов, бесплатных и платных, и OpenSSH является наиболее широко используемым клиентом. Он доступен на всех основных платформах, включая Linux, OpenBSD, Windows и macOS. Клиент OpenSSH предустановлен в большинстве дистрибутивов Linux по умолчанию, однако если в вашей системе не установлен клиент ssh, вы можете установить его с помощью диспетчера пакетов.
sudo apt install openssh-client
Как получить доступ к удаленному серверу
Для подключения к удаленному компьютеру вам потребуется его IP-адрес или имя. Загрузите терминал или любой SSH-клиент и введите ssh, а затем IP-адрес:
ssh 192.168.56.101
или имя:
ssh test.server.com
При первом подключении к хосту вы увидите следующее сообщение:
Введите yes и нажмите Enter. Возможно, вам также потребуется ввести свой пароль.
Укажите имя пользователя для SSH-подключения
SSH использует текущего пользователя при доступе к удаленному серверу. Чтобы указать пользователя для SSH-соединения, выполните команду в следующем формате:
ssh username@hostname_or_ip
Например:
ssh testuser@10.0.0.55
Примечание. Если вы столкнулись с ошибкой «Connection refused», обратитесь к нашему руководству, чтобы найти решения.
Используйте другой номер порта для SSH-соединения
По умолчанию сервер SSH прослушивает соединение на порту 22. Если настройка порта в файле конфигурации SSH была изменена, вам необходимо указать порт. В противном случае вы получите такую ошибку:
Чтобы подключиться к удаленному хосту с настраиваемым номером порта SSH, используйте флаг -p. Например:
ssh test.server.com -p 3322
Генерация ключей SSH с помощью SSH Keygen
Чтобы повысить безопасность соединений SSH, сгенерируйте пару ключей с помощью утилиты keygen. Пара состоит из открытого и закрытого ключей. Открытый ключ может быть общим, а закрытый ключ должен оставаться в безопасности.
Пары ключей SSH используются для автоматической аутентификации клиентов на серверах. Когда вы создаете пару ключей SSH, больше не нужно вводить пароль для доступа к серверу.
На терминале хост-машины используйте эту команду для создания пары ключей:
ssh-keygen -t rsa
Чтобы использовать настройки по умолчанию, нажмите Enter в ответ на запрос местоположения файла и парольной фразы.
Копировать открытый ключ SSH
Чтобы использовать пару ключей для аутентификации SSH, вам необходимо скопировать открытый ключ на сервер. Ключ - это файл id_rsa.pub, ранее созданный с помощью утилиты генерации ключей SSH.
Чтобы скопировать ключ на сервер, запустите эту команду на клиенте:
ssh-copy-id hostname_or_IP
Вы также можете указать имя пользователя, если не хотите использовать текущего пользователя.
Введите пароль для аутентификации, когда его спросят. После этого вам больше не нужно будет использовать пароль для подключения к тому же серверу.
Копирование файла удаленно через SSH с помощью SCP
Вы можете безопасно копировать файлы по протоколу SSH с помощью инструмента SCP. Базовый синтаксис:
scp fileName user@remotehost:/home/username/destination
Например, чтобы скопировать файл sample3 на рабочий стол на удаленном сервере с проверкой имени пользователя, введите:
scp sample3 test@10.0.10.5:/home/test/Desktop
Выходные данные показывают сводку операции.
Обязательно используйте флаг -P в верхнем регистре, если вам нужно указать порт.
Редактировать файл конфигурации SSH
Вы можете контролировать, как удаленные пользователи могут получить доступ к серверу через SSH. Измените настройки в файле sshd_config, чтобы настроить параметры сервера SSH. Обязательно редактируйте только те параметры, которые вам знакомы. Сервер может стать недоступным из-за неправильной конфигурации.
Используйте любой редактор по вашему выбору, чтобы отредактировать файл. Для внесения изменений вам потребуются права суперпользователя. В Linux мы используем vim.
В командной строке на удаленном хосте введите:
sudo vim /etc/ssh/sshd_config
Введите пароль sudo, и оболочка откроет файл в редакторе, который вы использовали.
Перезапустить службу SSH
Когда вы вносите изменения в конфигурацию SSH, вам нужно будет перезапустить службу в Linux.
В зависимости от дистрибутива Linux выполните одну из следующих команд на машине, на которой вы изменили настройки:
sudo ssh service restart
или:
sudo sshd service restart
Наконец, введите пароль, чтобы завершить процесс. В результате в следующем сеансе SSH будут использоваться новые настройки.
Выполнение команды на удаленном сервере с локального компьютера
Этот метод не создает новую оболочку. Вместо этого он запускает команду и возвращает пользователя в локальную подсказку. Вы можете создать файл, скопировать файлы или запустить любую другую команду SSH в этом формате.
Чтобы удаленно выполнить команду с локального компьютера, добавьте инструкцию к команде SSH. Например, чтобы удалить файл, введите:
ssh test.server.com rm ~/Desktop/Dir1/sample4
Введите пароль, и файл на удаленном сервере будет удален без создания новой оболочки.
Параметры командной строки SSH
Инструмент SSH имеет множество дополнительных параметров. Ниже перечислены общие параметры SSH и соответствующие описания.
-1 - указывает ssh использовать версию протокола 1
-2 - указывает ssh использовать протокол версии 2.
-4 - разрешает только адреса IPv4.
-6 - разрешает только адреса IPv6.
-A - включает переадресацию соединения агента аутентификации. Используйте эту опцию с осторожностью.
-a - Отключает переадресацию соединения агента аутентификации.
-b bind_address - используйте эту опцию на локальном хосте с более чем одним адресом, чтобы установить исходный адрес соединения.
-C - включает сжатие данных для всех файлов. Только для использования с медленными соединениями.
-c cipher_spec - используется для выбора спецификации шифра. Перечислите значения через запятую.
-E log_fileName - прикрепляет журналы отладки к log_file вместо стандартной ошибки.
-f - отправляет ssh в фоновый режим даже до ввода пароля или ключевой фразы.
-g - Разрешает удаленным хостам подключаться к портам, перенаправленным на локальном компьютере.
-q - запускает ssh в тихом режиме. Он подавляет большинство сообщений об ошибках и предупреждениях.
-V - отображает версию инструмента ssh и завершает работу.
-v - печатает отладочные сообщения для ssh-соединения. Подробный режим полезен при устранении неполадок конфигурации.
-X - Используйте этот параметр, чтобы включить пересылку X11.
-x - Отключить пересылку X11.
ClamAV является антивирусом с открытым исходным кодом. Его используют для обнаружения вирусов, вредоносных программ и вредоносного программного обеспечения на компьютерах под управлением Linux и даже в решениях именитых вендоров, так как эта разработка была выкуплена компанией Cisco, но все же оставлена в виде open-source. Угроза со стороны вирусов, троянов и других вредоносных программ всегда возможна, их количество растет в геометрической прогрессии как по количеству, так и по сложности, и антивирусное программное обеспечение всегда должно использовать сложные методы обнаружения. Никогда нельзя дать гарантии, что ваша система не станет жертвой этих нежелательных фрагментов кода, так что важно оставаться внимательным при использовании Интернета и совместном использовании файлов. Ну и отсюда вытекает необходимость реализации политик безопасности на основе здравого смысла и использовании современных антивирусных программ.
Установка ClamAV
Чтобы установить ClamAV в CentOS / RHEL 7, нам нужно установить репозиторий EPEL:
# yum install epel-release
Затем необходимо установить ClamAV со всеми его полезными инструментами:
# yum -y install clamav-server clamav-data clamav-update clamav-filesystem clamav clamav-scanner-systemd clamav-devel clamav-lib clamav-server-systemd
Настройка антивируса ClamAV
Для настройки ClamAV в первую очередь нам нужно удалить конфигурацию по умолчанию, чтобы создать свою:
# sed -i '/^Example/d' /etc/clamd.d/scan.conf
После удаления строк примера нужно сделать некоторые правки, чтобы определить тип сервера TCP и предоставить root права для запуска антивируса:
# vim /etc/clamd.d/scan.conf
Значение, данное с LocalSocket, является файлом, использующим связи с внешними процессами. Следует выполнить следующую строку:
LocalSocket /var/run/clamd.scan/clamd.sock
Добавляем эти две строки в конец файла и сохраняем:
User root
LocalSocket /var/run/clamd.<SERVICE>/clamd.sock
Чтобы поддерживать базу данных сигнатур ClamAV в актуальном состоянии, необходимо включить инструмент под названием Freshclam. Поэтому нужно создать файл резервной копии из его файла конфигурации:
# cp /etc/freshclam.conf /etc/freshclam.conf.bak
Freshclam читает свою конфигурацию из /etc/freshclam.conf. Файл содержит строку со словом Пример, чтобы пользователи не могли использовать значения по умолчанию, их необходимо удалить их или закомментировать, прежде чем сможем использовать freshclam. А так как не все настройки по умолчанию не подходят для наших целей, придется внимательно проверить файл и решить, что нам понадобится. Каждая команда также будет прокомментирована.
# sed -i '/^Example/d' /etc/freshclam.conf
Нам нужно запустить Freshclam, чтобы обновить базу данных и проверить, успешно ли задана конфигурация:
# freshclam
ClamAV update process started at Tue Nov 6 15:51:59 2018
WARNING: Can't query current.cvd.clamav.net
WARNING: Invalid DNS reply. Falling back to HTTP mode.
Reading CVD header (main.cvd): OK (IMS)
main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr)
Reading CVD header (daily.cvd): OK
Downloading daily-25006.cdiff [100%]
Downloading daily-25092.cdiff [100%]
Downloading daily-25093.cdiff [100%]
Downloading daily-25094.cdiff [100%]
Downloading daily-25095.cdiff [100%]
daily.cld updated (version: 25095, sigs: 2143057, f-level: 63, builder: neo)
Reading CVD header (bytecode.cvd): OK
bytecode.cvd is up to date (version: 327, sigs: 91, f-level: 63, builder: neo)
Database updated (6709397 signatures) from database.clamav.net (IP: 104.16.186.138)
Процесс выводит свой прогресс-бар в терминал, и вы можете увидеть несколько сообщений об ошибках. Например, он может сообщить, что ему не удалось загрузить нужный файл. Не паникуйте - freshclam попробует несколько зеркал. Он сообщает, что main.cvd, daily.cvd и bytecode.cvd обновляются, и по завершении, вы будете знать, что у вас есть последние сигнатуры.
Мы можем запустить freshclam в любое время, когда необходимо убедиться, что базы данных сигнатур обновлены, но было бы неудобно всегда запускать его вручную. При запуске с аргументом -d freshclam будет работать и периодически проверять наличие обновлений в течение дня (по умолчанию каждые два часа).
Чтобы сохранить некий порядок в системе, мы создали файл службы для запуска freshclam и зарегистрировали его в systemd:
# vim /usr/lib/systemd/system/clam-freshclam.service
Затем мы помещаем следующий код в файл и сохраняем его:
[Unit]
Description = freshclam scanner
After = network.target
[Service]
Type = forking
ExecStart = /usr/bin/freshclam -d -c 4
Restart = on-failure
PrivateTmp = true
RestartSec = 20sec
[Install]
WantedBy=multi-user.target
Раздел [Unit] определяет основные атрибуты сервиса, такие как его описание и его зависимость от сетевого соединения. Раздел [Service] определяет сам сервис, ExecStart будет запускать freshclam с аргументом -d, Type сообщает systemd, что процесс будет разветвляться и запускаться в фоновом режиме, а при перезапуске systemd отслеживает сервис и перезапускает его автоматически в случае. Раздел [Install] определяет, как он будет связан, когда запустится systemctl enable.
Перезагрузите systemd, чтобы применить изменения:
# systemctl daemon-reload
Далее запустите и включите сервис freshclam:
# systemctl start clam-freshclam.service
# systemctl status clam-freshclam.service
clam-freshclam.service - freshclam scanner
oaded: loaded (/usr/lib/systemd/system/clam-freshclam.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2018-11-06 15:56:53 IST; 3s ago
Process: 7926 ExecStart=/usr/bin/freshclam -d -c 4 (code=exited, status=0/SUCCESS)
Main PID: 7927 (freshclam)
CGroup: /system.slice/clam-freshclam.service
L-7927 /usr/bin/freshclam -d -c 4
Nov 06 15:56:53 node2.example.com systemd[1]: Starting freshclam scanner...
Nov 06 15:56:53 node2.example.com systemd[1]: Started freshclam scanner.
Nov 06 15:56:53 node2.example.com freshclam[7927]: freshclam daemon 0.100.2 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
Nov 06 15:56:53 node2.example.com freshclam[7927]: ClamAV update process started at Tue Nov 6 15:56:53 2018
Если все работает нормально, добавляем его в службу запуска системы:
# systemctl enable clam-freshclam.service
Created symlink from /etc/systemd/system/multi-user.target.wants/clam-freshclam.service to /usr/lib/systemd/system/clam-freshclam.service.
Теперь для настройки ClamAV необходимо создать файл сервиса ClamAV. У нас есть пример файла службы, который нам нужно скопировать в папку системных служб. Нам нужно изменить его имя на что-то понятное. Затем нам нужно внести в него небольшие изменения:
# mv /usr/lib/systemd/system/clamd@.service /usr/lib/systemd/system/clamd.service
Поскольку мы изменили имя, нам нужно изменить его в файле, который также использует этот сервис:
# vim /usr/lib/systemd/system/clamd@scan.service
Мы изменили первую строку, удалив @, чтобы это выглядело так:
.include /lib/systemd/system/clamd.service
В том же месте нам нужно изменить файл сервиса Clamd:
# vim /usr/lib/systemd/system/clamd.service
Мы добавляем следующие строки в конце:
[Install]
WantedBy=multi-user.target
Удаляем % i из опций Description и ExecStart. Затем изменяем их, чтобы они выглядели следующим образом:
Description = clamd scanner daemon
ExecStart = /usr/sbin/clamd -c /etc/clamd.d/scan.conf
TimeoutSec=5min
Restart = on-failure
RestartSec=10sec
Далее запустите сервис clamv
# systemctl start clamd.service
# systemctl status clamd.service
clamd.service - clamd scanner daemon
Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2018-11-06 19:48:17 IST; 16s ago
Docs: man:clamd(8)
man:clamd.conf(5)
https://www.clamav.net/documents/
Process: 1460 ExecStart=/usr/sbin/clamd -c /etc/clamd.d/scan.conf (code=exited, status=0/SUCCESS)
Main PID: 1461 (clamd)
CGroup: /system.slice/clamd.service
L-1461 /usr/sbin/clamd -c /etc/clamd.d/scan.conf
Nov 06 19:48:15 node2.example.com clamd[1461]: ELF support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: Mail files support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: OLE2 support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: PDF support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: SWF support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: HTML support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: XMLDOCS support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: HWP3 support enabled.
Nov 06 19:48:15 node2.example.com clamd[1461]: Self checking every 600 seconds.
Nov 06 19:48:17 node2.example.com systemd[1]: Started clamd scanner daemon.
Если все хорошо, то включите сервис clamd.
# systemctl enable clamd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/clamd.service to /usr/lib/systemd/system/clamd.service.
Для проверки текущей папки мы запускаем следующую команду:
# clamscan --infected --remove --recursive ./
----------- SCAN SUMMARY -----------
Known viruses: 6702413
Engine version: 0.100.2
Scanned directories: 7
Scanned files: 9
Infected files: 0
Data scanned: 0.01 MB
Data read: 0.00 MB (ratio 2.00:1)
Time: 25.439 sec (0 m 25 s)
Мы надеемся вы правильно выполнили все этапы настройки ClamAV в RHEL / CentOS 7 Linux и они оказались полезны для вас в том или ином виде.