По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Жизнь системного администратора не проста. Поддержка систем, безопасность сетевого контура, решение проблем - уследить за всем сложно. Пользовательские пароли – важный нюанс и их, безусловно, нужно менять с определенной периодичностью.
В статье расскажем, как автоматически заставлять пользователей Linux сменить их пароли.
Срок действия паролей
Чтобы получить информацию о пользовательских паролях и о дате их окончания введите команду:
chage -l
Будет выведена следующая информация:
Когда пароль был последний раз изменен;
Дата окончания действия пароля;
Сколько дней осталось до окончания действия пароля;
Когда учетная запись пользователя будет закончена (можно, пожалуйста, далее мы будем говорить «заэкспайрится»?)
Минимальное количество дней между итерацией смены пароля;
Максимальное количество дней между итерацией смены пароля;
Заставляем пользователя менять пароль каждые 90 дней
Следующей командой вы можете поставить жесткое правило смены паролей:
sudo chage -M 90
Команду можно выполнить от root пользователя или от юзера с sudo правами. Проверить, что настройка установлена корректно, можно с помощью команды chage -l
Срок действия учетной записи
Представьте, у вас есть два юзера: Иван и Петр. И доступ им нужно организовать на 2 дня, с момента сегодняшней даты (сегодня echo rus_date("j F");). Получается, создаем им пользователей:
sudo adduser ivan
sudo adduser petr
Создаем пароли для них:
sudo passwd ivan
sudo passwd petr
Как мы уже сказали, Иван и Петр уезжают через 2 дня. Соответственно, делаем для них следующую конфигурацию:
sudo chage -E echo date("Y-m-d", strtotime("+2 days")); ivan
sudo chage -E echo date("Y-m-d", strtotime("+2 days")); petr
Если вы запустите команду chage -l , то увидите актуальную дату жизни аккаунта. Как только аккаунты Ивана и Петра заэкспайрятся, их можно будет удалить командой:
sudo chage -E -1 ivan
sudo chage -E -1 petr
Сколько времени на смену пароля?
Пароль Геннадия заэкспайрился (истек срок годности) в воскресение. Мы дадим Гене 5 дней, чтобы он зашел в свою учетную запись и сменил пароль. Если он этого не сделает, аккаунт будет заблокирован. Сделать это можно вот так:
sudo chage -I 5 gennady
Ну, а если Геннадий так и не сменит пароль и учетная запись заблокируется, удалить ее можно вот так:
sudo chage -I -1 gennady
Предупреждения для пользователей
Вы – адекватный человек. И наверняка хотите, чтобы ваши юзеры были уведомлены о смене пароля заранее. Например, чтобы Геннадий узнал, что через 7 дней истекает срок годности его пароля, дайте следующую команду:
sudo chage -W 7 gennady
Защищаемся от частой смены паролей
Вдруг в вашем штате завелся очень взволнованный безопасностью сотрудник, который меняет пароли каждый день? Такое. Чтобы сделать минимальное количество дней между сменой паролей в две недели (14 дней), можно указать следующую команду:
sudo chage -m 14 sergey
Сделали большой лимит и передумали? Не проблема – удалить ограничение в днях можно вот так:
sudo chage -m 0 sergey
В интерфейсе Elastix 4 существует большое множество инструментов, позволяющих осуществлять автоматическое распределение звонков. Про один из таких инструментов, мы расскажем в сегодняшней статье. Речь пойдёт о модуле Follow Me, с помощью которого можно перенаправить звонок, поступивший на определенный внутренний номер по любому направлению, доступному на IP-АТС.
Настройка
Давайте перейдём к настройке. Для того, чтобы попасть в модуль проходим следующий путь – с главной страницы - PBX → PBX Configuration → Follow Me, откроется следующее окно:
Справа находится список доступных внутренних номеров (Extensions), настроенных на нашей IP-АТС, для которых мы будем настраивать правила Follow Me. Для каждого Extension’а правила настраиваются отдельно. Выберем из списка нужный номер, например - 112 – Operator2, откроется функционал модуля Follow Me:
Как видно, функционал модуля делится на 4 части - Edit Follow Me, Call Confirmation Configuration, Change External CID Configuration и Destination if no answer
Если нажать в самом верху на кнопку Edit Extension 112, то мы попадаем в модуль настройки внутреннего номера – Extensions, для номера 112. Нажав на кнопку Delete Entries, мы удалим правила Follow Me для номера 112.
Раздел Edit Follow Me
Данном разделе настраиваются основные правила модуля, а именно – стратегия обзвона, время, в течение которого будет звонить телефон 112, прежде чем переключиться на другие номера, список номеров, на которые необходимо распределить звонок по определенной стратегии и т.п. Рассмотрим доступные функции данного раздела:
Disable - Включает или отключает правила Follow Me для данного номера
Initial Ring Time - Время, в течение которого АТС будет пытаться установить соединение с данным номером, прежде чем включатся правила Follow Me и не пойдёт обзвон номеров из списка Follow-me List
Ring Strategy - Стратегия обзвона номеров из списка Follow-me List
Ring Time - Время, в течение которого будут АТС будет пытаться установить соединение с номерами, указанными в Follow-me List. Максимально возможное значение – 60 секунд
Follow-Me List - Список номеров, на которые необходимо распределить вызов по выбранной в Ring Strategy стратегии. Можно отправлять вызовы на внешние и мобильные номера, для этого нужно указать префикс выхода на внешнюю линию, которую использует ваш провайдер, сам мобильный или внешний номер и в конце обязательно #. Например 984951234567# - где 8 – префикс выхода на внешнюю линию.
Extension Quick Pick - На каком номере должна закончиться стратегия обзвона
Announcement - Голосовое сообщение. Можно например сообщить, что вызов переводится на секретаря. Записи добавляются через модуль - System Recordings
Play Music On Hold? - Проигрывать ли Music On Hold
CID Name Prefix - Опционально можно добавить звонкам некий префикс, который будет отображаться на телефонах при звонке по правилам Follow Me.
Alert Info - Данная опция помогает различить звонки с разных SIP устройств
Раздел Call Confirmation Configuration
Данный раздел помогает настроить опции подтверждения принятия звонка. Особенно полезно, когда в Follow Me указаны внешние номера.
Confirm Calls - Если данная опция включена и звонок уходит на внешний номер, то удаленной стороне будет озвучено предложение “нажмите 1 если хотите принять звонок”.
Remote Announce - Сообщение удаленной стороне с предложением принять звонок, например - “нажмите 1 если хотите принять звонок”
Too-Late Announce - Сообщение удаленной стороне о том, что звонок уже успели принять, прежде чем они нажали цифру 1
Раздел Change External CID Configuration
В данном разделе доступны настройки отображения CallerID:
Destination if no Answer
Данный раздел позволяет настроить правила, по которым будет обрабатываться звонок, если ни один из номеров в списке Follow-Me List его не принял. Это может быть любое направление, доступное на IP-АТС – IVR, группа обзвона, голосовая почта и прочие.
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через 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.