Администрирование Linux (CentOS). Настройка системной почты

Стоимость курса: 10.000 руб.
Описание курса:
Любой системный администратор мечтает о надежной операционной системе. Освойте CentOS – дистрибутив Linux корпоративного класса, известный своей стабильностью!
Зная администрирование Linux на профессиональном уровне, вы сможете автоматизировать большинство своих повседневных задач за счет скриптов и минимизировать затраты на содержание сервера.
Изучите самую надежную бесплатную ОС и станьте специалистом по серверным технологиям!
В результате обучения вы научитесь:
Осуществлять установку и развертывание Linux CentOS

Работать с файловой системой Linux

Управлять учетными записями и правами доступа

Методам работы с командными оболочками и основам создания сценариев

Основам администрирования стека TCP/IP и базовым инструментам для работы с сетью

Программа курса «Администрирование Linux»:
Введение в Linux

Файловая система
Корневой каталог, точка монтирования, домашний каталог, типы файлов. Обычные файлы. Каталоги. Файлы устройств. Команды. Навигация по файловой системе: команды cd, pushd, popd, pwd. Создание, удаление и копирование файлов. Команды touch, rm, cp. Операции с каталогами. Команды mkdir и rmdir.

Учетные записи
Понятие учетной записи и аутентификации. Файлы /etc/passwd и /etc/group, /etc/shadow и /etc/gshadow. Учетная запись root. Пароли в Linux. Команды login, su, newgrp, passwd, gpasswd, chage.

Права доступа
Распределение прав доступа в Linux. Чтение. Запись. Выполнение. Особенности прав у каталогов. Назначение прав доступа.Команды chmod, chown, chgrp. Sticky bit.

Работа с файлами
Вывод информации из файлов на экран консоли. Команды cat, tac, more, less, head, tail, od. Перенаправление вывода. Понятие stdin, stdout, stderr. Каналы. Операторы | и <, >, >> . Фильтрование информации. Регулярные выражения. Команда grep. Архивирование. Утилиты tar и gzip.

Процессы в Linux
Идентификаторы процессов. Демоны. Команда ps . Права доступа процессов. Реальный и эффективный идентификаторы. Биты SUID и SGID. Управление процессами. Сигналы. Команды nice, nohup, kill, killall.

Командные оболочки
Обзор командных оболочек. Командная оболочка bash. Многозадачность в консоли. Управление заданиями. Переменные среды Midnight commander. для Bash.

Планирование заданий
Работа с дисковыми накопителями. Демон cron. Команды at, crontab, mount.

Текстовые редакторы vi, Emacs

Уровни инициализации SVR4
Процесс init. Уровни инициализации. Файл /etc/inittab. Каталог /etc/rc.d.

Система X Window
Демон X. Запуск X. Скрипт startx . 5-й уровень инициализации.

Сетевое администрирование Linux
Сетевая модель OSI. Протоколы IP, UDP, TCP, ICMP. Iptables

Скачать:

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

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

Начальная настройка CentOS 7

Итак, у нас имеется: # uname -a Linux zeroxzed.ru 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Первым делом обновим базовую систему:

# yum update

Для удобства администрирования, я всегда устанавливаю Midnight Commander, или просто mc:

# yum install mc

И сразу же для него включаю подсветку синтаксиса всех файлов, которые не обозначены явно в файле /usr/share/mc/syntax/Syntax синтаксисом для sh и bash скриптов. Этот универсальный синтаксис нормально подходит для конфигурационных файлов, с которыми чаще всего приходится работать на сервере. Перезаписываем файл unknown.syntax . Именно этот шаблон будет применяться к.conf и.cf файлам, так как к ним явно не привязано никакого синтаксиса.

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

# ifconfig

И увидите ответ:

Bash: ifconfig: command not found

По крайней мере я, когда впервые это увидел, прилично удивился. Подумал, что ошибся в написании команды, перепроверил все несколько раз, но без результата. Оказалось, что надо отдельно установить пакет для выполнения ifconfig и прочих сетевых утилит.

Вместо ifconfig в CentOS 7 теперь утилита ip . Я не понимаю, зачем пилить отдельные программы для управления сетевыми настройками, если ifconfig и так отлично справляется с задачей. К тому же мне всегда нравилось, что в различных дистрибутивах линукс все примерно одинаковое. С помощью ifconfig можно настроить сеть не только в linux, но и в freebsd. Это удобно. А когда в каждом дистрибутиве свой инструмент это неудобно. Так что предлагаю установить привычный ifconfig.

Сделаем это:

# yum install net-tools

Теперь, чтобы у нас работали команды nslookup или, к примеру, host необходимо установить пакет bind-utils. Если этого не сделать, то на команду:

# nslookup

Будет вывод:

Bash: nslookup: command not found

Так что устанавливаем bind-utils:

# yum install bind-utils

Отключаем SELinux. Его использование и настройка отдельный разговор. Сейчас я не буду этим заниматься. Так что отключаем:

# mcedit /etc/sysconfig/selinux

меняем значение
SELINUX=disabled
Чтобы изменения вступили в силу, перезагружаемся:

# reboot

Можно без перезагрузки применить отключение SElinux:

# setenforce 0

Указываем сетевые параметры

Не используйте одновременно оба демона синхронизации времени — chrony и ntp. Выберите какой-нибудь один. Лично я не вижу в них разницы, сам чаще всего ставлю привычный ntp.

Добавление репозиториев

Для инсталляции различного софта необходимо . Наиболее популярные это EPEL и rpmforge, поэтому добавим их. Сначала ставим EPEL. С ним все просто, он добавляется из стандартного репозитория:

# yum install epel-release

Устанавливаем rpmforge:

# rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt # yum install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

# yum install http://repository.it4i.cz/mirrors/repoforge/redhat/el7/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

Настройка хранения истории в bash_history

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

По-умолчанию, сохраняются только последние 1000 команд. Если их будет больше, то более старые будут удаляться и заменяться новыми.
Не указаны даты выполнения команд, только их список в порядке выполнения.
Файл со списком команд обновляется после завершения сессии. При параллельных сессиях часть команд может быть утеряна.
Сохраняются абсолютно все команды, хотя в хранении некоторых нет никакого смысла.

Список последних выполненных команд хранится в домашней директории пользователя в файле .bash_history (в начале точка). Его можно открыть любым редактором и посмотреть. Для более удобного вывода списка, можно в консоли ввести команду:

# history

и увидеть пронумерованный список. Быстро найти конкретную команду, можно с помощью фильтрации только нужных строк, например вот так:

# history | grep yum

Так мы увидим все варианты запуска команды yum, которые хранятся в истории. Исправим перечисленные недостатки стандартных настроек хранения истории команд в CentOS 7. Для этого нужно отредактировать файл .bashrc , который находится в том же каталоге, что и файл с историей. Добавляем в него следующие строки:

Export HISTSIZE=10000 export HISTTIMEFORMAT="%h %d %H:%M:%S " PROMPT_COMMAND="history -a" export HISTIGNORE="ls:ll:history:w:htop"

Первый параметр увеличивает размер файла до 10000 строк. Можно сделать и больше, хотя обычно хватает такого размера. Второй параметр указывает, что необходимо сохранять дату и время выполнения команды. Третья строка вынуждает сразу же после выполнения команды сохранять ее в историю. В последней строке мы создаем список исключений для тех команд, запись которых в историю не требуется. Я привел пример самого простого списка. Можете дополнить его на свое усмотрение.

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

# source ~/.bashrc

Автоматическое обновление системы

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

Для автоматической проверки обновлений нам поможет утилита yum-cron . Ставится она традиционно через yum из стандартного репозитория.

# yum install yum-cron

После установки создается автоматическое задание на выполнение утилиты в /etc/cron.daily и /etc/cron.hourly . По-умолчанию, утилита скачивает найденные обновления, но не применяет их. Вместо этого, администратору на локальный почтовый ящик root отправляется уведомление об обновлениях. Дальше вы уже в ручном режиме заходите и решаете, устанавливать обновления или нет в удобное для вас время. Мне такой режим работы видится наиболее удобным, поэтому я не меняю эти настройки.

Конфигурационные файлы yum-cron находятся по адресу /etc/yum/yum-cron.conf и yum-cron-hourly.conf . Они неплохо прокомментированы, так что в подробных разъяснениях не нуждаются. Обращаю внимание на раздел , где можно указать параметры отправки сообщений. По-умолчанию стоит отправка почты через локальный хост. Можно тут изменить параметры и отправлять сообщения через сторонний почтовый сервер. Но вместо этого лично я предпочитаю глобально для всего сервера настроить пересылку локальной почты root на внешний почтовый ящик через авторизацию на другом smtp сервере.

Отключаем флуд сообщений в /var/log/messages

В дефолтной установке системы CentOS 7, весь ваш системный лог /var/log/messages через некоторое время работы сервера будет забит следующими записями.

Oct 16 14:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 14:01:01 xs-files systemd: Starting user-0.slice. Oct 16 14:01:01 xs-files systemd: Started Session 14440 of user root. Oct 16 14:01:01 xs-files systemd: Starting Session 14440 of user root. Oct 16 14:01:01 xs-files systemd: Removed slice user-0.slice. Oct 16 14:01:01 xs-files systemd: Stopping user-0.slice. Oct 16 15:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 15:01:01 xs-files systemd: Starting user-0.slice. Oct 16 15:01:01 xs-files systemd: Started Session 14441 of user root. Oct 16 15:01:01 xs-files systemd: Starting Session 14441 of user root. Oct 16 15:01:01 xs-files systemd: Started Session 14442 of user root. Oct 16 15:01:01 xs-files systemd: Starting Session 14442 of user root. Oct 16 15:01:01 xs-files systemd: Removed slice user-0.slice. Oct 16 15:01:01 xs-files systemd: Stopping user-0.slice. Oct 16 16:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 16:01:01 xs-files systemd: Starting user-0.slice. Oct 16 16:01:01 xs-files systemd: Started Session 14443 of user root. Oct 16 16:01:01 xs-files systemd: Starting Session 14443 of user root. Oct 16 16:01:01 xs-files systemd: Removed slice user-0.slice.

Никакой практической пользы они не несут, поэтому отключим их. Для этого создадим отдельное правило для rsyslog, где перечислим все шаблоны сообщений, которые будем вырезать. Разместим это правило в отдельном файле /etc/rsyslog.d/ignore-systemd-session-slice.conf .

# cd /etc/rsyslog.d && mcedit ignore-systemd-session-slice.conf if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of") then stop

Сохраняем файл и перезапускаем rsyslog для применения настроек.

# systemctl restart rsyslog

Необходимо понимать, что в данном случае мы отключаем флуд в лог файл только на локальном сервере. Если вы храните логи на , то данное правило нужно будет настраивать именно на нем.

Установка iftop, atop, htop, lsof на CentOS 7

И напоследок добавим несколько полезных утилит, которые могут пригодиться в процессе эксплуатации сервера.

iftop показывает в режиме реального времени загрузку сетевого интерфейса, может запускаться с различными ключами, не буду останавливаться на этом подробно, в интернете есть информация на эту тему. Ставим:

# yum install iftop

И два интересных диспетчера задач, я чаще всего пользуюсь htop, но иногда пригодится и atop. Ставим оба, сами посмотрите, разберетесь, что вам больше нравится, подходит:

# yum -y install htop # yum -y install atop

Вот как выглядит htop:

Для вывода информации о том, какие файлы используются теми или иными процессами, советую поставить утилиту lsof . Она скорее всего рано или поздно пригодится, когда будете диагностировать работу сервера.

# yum install wget bzip2 traceroute gdisk

На этом у меня все. Базовая настройка CentOS 7 закончена, можно приступать к установке и настройке основного функционала.

Настройка системной почты

В завершение настройки сервера CentOS 7 сделаем так, что бы почта, адресованная локальному root, отправлялась через внешний почтовый сервер на выбранный почтовый ящик. Если этого не сделать, то она будет локально складываться в файл /var/spool/mail/root . А там может быть важная и полезная информация. Настроим ее отправку в ящик системного администратора.

Подробно об этом я рассказал в отдельной статье — . Здесь кратко только команды и быстрая настройка. Ставим необходимые пакеты:

# yum install mailx cyrus-sasl cyrus-sasl-lib cyrus-sasl-plain

Рисуем примерно такой конфиг для postfix.

Cat /etc/postfix/main.cf ## DEFAULT CONFIG BEGIN ###################### queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix mail_owner = postfix inet_interfaces = localhost inet_protocols = all unknown_local_recipient_reject_code = 550 alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.10.1/samples readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES ## DEFAULT CONFIG END ###################### # Имя сервера, которое выводит команда hostname myhostname = centos7-test.xs.local # Здесь по логике нужно оставлять только домен, но в данном случае лучше оставить полное имя сервера, чтобы в поле отправитель # фигурировало полное имя сервера, так удобнее разбирать служебные сообщения mydomain = centos7-test.xs.local mydestination = $myhostname myorigin = $mydomain # Адрес сервера, через который будем отправлять почту relayhost = mailsrv.mymail.ru:25 smtp_use_tls = yes smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_tls_security_level = may

Создаем файл с информацией об имени пользователя и пароле для авторизации.

# mcedit /etc/postfix/sasl_passwd mailsrv.mymail.ru:25 [email protected]:password

Создаем db файл.

# postmap /etc/postfix/sasl_passwd

Теперь можно перезапустить postfix и проверить работу.

# systemctl restart postfix

К стандартному алиасу для root в /etc/aliases , добавьте внешний адрес, куда будет дублироваться почта, адресованная root. Для этого редактируем указанный файл, изменяя последнюю строку.

#root: marc

Root: root,[email protected]

Обновляем базу сертификатов:

# newaliases

Отправим письмо через консоль локальному руту:

# df -h | mail -s "Disk usage" root

Письмо должно уйти на внешний ящик. На этом настройка локальной почты закончена. Теперь все письма, адресованные локальному root, например, отчеты от cron, будут дублироваться на внешний почтовый ящик, причем с отправкой через нормальный почтовый сервер. Так что письма будут нормально доставляться, не попадая в спам (хотя не обязательно, есть еще эвристические фильтры).

Заключение

Мы выполнили некоторые начальные шаги по настройке сервера CentOS 7, которые я обычно делаю при подготовке сервера. Я не претендую на абсолютную истину, возможно что-то упускаю или делаю не совсем верно. Буду рад разумным и осмысленным комментариям и замечаниям с предложениями.

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

, либо только подключение centos к мониторингу путем установки на него агента.
В отдельной рубрике автора

Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.

В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет - оставим за кадром.

В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7.

Введение

Systemd приносит концепцию юнитов systemd. Юниты представлены конфигурационными файлами, размещенными в одной из директорий:

/usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
/run/systemd/system/ - юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
/etc/systemd/system/ - юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.

Типы юнитов systemd:

.service – системный сервис
.target - группа юнитов systemd
.automoun t – точка автомонтирования файловой системы
.device – файл устройства, распознанного ядром
.mount – точка монтирования файловой системы
.path – файл или директория в файловой системе
.scope – процесс, созданный извне
.slice – группа иерархически организованных юнитов, управляющая системными процессами
.snapshot – сохраненное состояние менеджера systemd
.socket – сокет межпроцессного взаимодействия
.swap – Свап-устройство или свап-файл (файл подкачки)
.timer – таймер systemd

Основные функции systemd в CentOS 7

Активация, основанная на сокетах . Во время загрузки systemd прослушивает сокеты для всех системных сервисов, поддерживает этот тип активации и передает сокеты этим сервисам сразу после старта сервисов. Это позволяет systemd не только запускать сервисы параллельно, но также дает возможность перезапускать сервисы без потери любых отправленных им сообщений, пока сервисы были недоступны. Соответствующий сокет остается доступным и все сообщения выстраиваются в очередь.
Активация, основанная на D-Bus . Системные сервисы, использующие D–Bus для межпроцессного взаимодействия, могут быть запущены по требованию, когда клиентское приложение пытается связаться с ними.
Активация, основанная на девайсах . Системные сервисы, поддерживающие активацию, основанную на девайсах, могут быть запущены, когда определенный тип оборудования подключается или становится доступным.
Активация, основанная на путях . Системные сервисы могут поддерживать этот вид активации, если изменяется состояние папки или директории.
Снепшоты системных состояний . Система может сохранять состояние всех юнитов и восстанавливать предыдущее состояние системы.
Управление точками монтирования и автомонтирования . Systemd отслеживает и управляет точками монтирования и автомонтирования.
Агрессивная параллелизация Systemd запускает системные сервисы параллельно из-за использования активации, основанной на сокетах. В комбинации с сервисами, поддерживающими активацию по требованию, параллельная активация значительно уменьшает время загрузки системы.
Транзакционная логика активации юнитов . До активации и деактивации юнитов systemd вычисляет их зависимости, создает временную транзакцию и проверяет целостность этой транзакции. Если транзакция нецелостная, systemd автоматически пытается исправить ее и удалить не требующиеся задания из нее до формирования сообщения об ошибке.
Обратная совместимость с инициализацией SysV . SystemD полностью поддерживает скрипты инициализации SysV, как описано в спецификации Linux Standard Base (LSB), что упрощает переход на systemd.

Управление сервисами

В предыдущих версиях CentOS использовалась SysV или Upstart. Скрипты инициализации располагались в директории /etc/rc.d/init.d/ . Такие скрипты обычно писались на Bash и позволяли администратору управлять состоянием сервисов и демонов. В CentOS 7 скрипты инициализации были заменены сервисными юнитами.

По способу использования сервисные юниты .service напоминают скрипты инициализации. Для просмотра, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl . Команды service и chkconfig по-прежнему включены в систему, но только по соображениям совместимости.

При использовании systemctl указывать расширение файла не обязательно.

Ниже представлены основные команды systemctl :

systemctl start name.service – запуск сервиса.
systemctl stop name.service - остановка сервиса
systemctl restart name.service - перезапуск сервиса
systemctl try-restart name.service - перезапуск сервиса только, если он запущен
systemctl reload name.service - перезагрузка конфигурации сервиса
systemctl status name.service - проверка, запущен ли сервис с детальным выводом состояния сервиса
systemctl is-active name.service - проверка, запущен ли сервис с простым ответом: active или inactive
systemctl list-units --type service --all – отображение статуса всех сервисов
systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
systemctl disable name.service – деактивирует сервис
systemctl reenable name.service – деактивирует сервис и сразу активирует его
systemctl is–enabled name.service – проверяет, активирован ли сервис
systemctl list-unit-files --type service – отображает все сервисы и проверяет, какие из них активированы
systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd

Работаем с целями (targets) Systemd

Предыдущие версии CentOS с SysV init или Upstart включали предопределенный набор уровней запуска (runlevels), которые представляли специфичные режимы для операций, пронумерованные от 0 до 6. В CentOS 7 концепция уровней запуска была заменена целями systemd.

Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например юнит graphical.target , использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service ) и Accounts Service (accounts–daemon.service ) и активирует multi–user.target . В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service ) или D-Bus (dbus.service ) и активирует другие целевые юниты basic.target .

В CentOS 7 присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют алиасы на эти цели, которые напрямую отображаются в уровнях запуска SysV.

poweroff.target (runlevel0.target) – завершение работы и отключение системы
rescue.target (runlevel1.target) – настройка оболочки восстановления
multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы
graphical.target (runlevel5.target) – настройка графической многопользовательской системы
reboot.target (runlevel6.target) – выключение и перезагрузка системы

Команды runlevel и telinit по-прежнему доступны, но оставлены в системе по соображениям совместимости. Рекомендуется использовать systemctl для изменения или настройки системных целей.

Для определения, какой целевой юнит используется по умолчанию, полезна следующая команда: systemctl get–default .

Для просмотра всех загруженных целевых юнитов воспользуйтесь командой systemctl list-units --type target , а для просмотра вообще всех целевых юнитов командой: systemctl list-units --type target --all .

Для изменения цели по умолчанию поможет команда systemctl set-default name.target .

Для изменения текущей цели: systemctl isolate name.target . Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.

В CentOS 7 systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомандуется использовать systemctl:
systemctl halt – останавливает систему
systemctl poweroff – выключает систему
systemctl reboot – перезагружает систему

Управление systemd на удаленной машине

Systemd позволяет управлять удаленной машиной по SSH. Для управления используйте команду:
systemctl --host user_name@host_name command , где user_name – имя пользователя, host_name – имя хоста, которым осуществляется удаленное управление, а command – выполняемая команда systemd.

Типичный systemd .service

Этот раздел поможет вам, если вам необходимо быстро сделать поддержку управления сервисом из systemd. Подробная информация о всех параметрах файла.service есть в соответствующем разделе документации по systemd.

Description=Daemon to detect crashing apps After=syslog.target ExecStart=/usr/sbin/abrtd Type=forking WantedBy=multi-user.target

Давайте посмотрим на секцию . Она содержит общую информацию о сервисе. Такая секция есть не только в сервис-юнитах, но и в других юнитах (например при управлении устройствами, точками монтирования и т.д.). В нашем примере мы даем описание сервиса и указываем на то, что демон должен быть запущен после Syslog.

В следующей секции непосредственно содержится информация о нашем сервисе. Используемый параметр ExecStart указывает на исполняемый файл нашего сервиса. В Type мы указываем, как сервис уведомляет systemd об окончании запуска.

Финальная секция содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target .

Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/имя_сервиса.service. Выполните команды systemctl daemon-reload . Systemd узнает о сервисе и вы сможете его запустить.

Дополнительная информация

Отличное руководство по systemd от RedHat , положенное в основу этой статьи.
Документация по написанию своего сервис-юнита systemd .
«Systemd для администраторов» от разработчика systemd на русском языке.

Заключение

В этой статье мы научились управлять сервисами CentOS 7. Конечно, это далеко не единственная функция systemd и другие ее стороны будут рассмотрены в будущем. Сама ОС практически со времени релиза доступна на классических VPS и облачных VPS от Infobox. Попробуйте systemd прямо сейчас. Эти знания будут полезны в связи с переходом многих дистрибутивов на systemd.

Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней.
В случае, если вы не можете оставлять комментарии на Хабре, можно написать их в блоге

Приветствую, коллеги. Долгое время проект NetSkills был посвящен исключительно сетевым технологиям - Курс молодого бойца, Основы GNS, UNetLab . Однако от подписчиков все чаще звучал вопрос: “А что еще должен знать сетевой инженер или системный администратор?” . Тут можно привести большой список технологий/направлений и в итоге сделать вывод, что знать только сети - недостаточно ! Совершенно очевидно, что для успешной карьеры нужно намного больше. Поэтому было принято решение расширить проект и для начала выпустить курс “Linux для начинающих”.

Немаловажная деталь, преподаватель - девушка , которая совсем недавно примкнула к проекту NetSkills . Чему же может научить девушка? Если вы заинтересовались, добро пожаловать под кат…

Цель курса – изучить основы администрирования операционных систем Linux. Материал по большей части практический и содержит минимальное количество теории. Курс подойдет как для начинающих системных администраторов, которые занимаются настройкой серверов компании, так и для сетевых инженеров, т.к. бОльшая часть сетевого оборудования работает под управлением Linux (особенно если учитывать тенденцию импортозамещения), поэтому навыки работы с этой системой им однозначно не помешают. Да и вообще, каждый уважающий себя ИТ-шник просто обязан обладать базовыми навыками работы с Linux системами. Ценность такого сотрудника сразу вырастает.

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

В план базового курса вошли следующие темы:
1.Цели изучения операционной системы Linux, ее основные преимущества.
2.Создание виртуальных машин.
3.Установка операционной системы CentOS.
4.Структура файловой системы Linux.
5.Основные команды, необходимые для работы в консоли Linux (cd, ls, man, grep, find, cp, mv, rm и т.д.).
6.Настройка сети в CentOS. Утилиты Putty, WinSCP.
7.Основы безопасности. Заведение новых пользователей в системе.
8.Установка пакетов. Пакетный менеджер. Репозитории.
9.Файловый менеджер mc, текстовый редактор nano и сетевые утилиты (ifconfig, nslookup, arp, telnet).
10.Настройка шлюза доступа в Интернет. Iptables. NAT. DHCP.

Итак, зачем изучать линукс и каковы его преимущества? Полагаю, стоит начать с определения.
GNU/Linux – это семейство unix-подобных операционных систем, основанных на ядре Linux. ОС из этого семейства распространяются обычно бесплатно в виде так называемых дистрибутивов, содержащих помимо самой ОС еще и набор прикладного ПО (т.е. по сути сборка). Дистрибутивов Linux на сегодняшний день существует огромное количество, но почти все они являются потомками трех основных дистрибутивов: Debian, Slackware и Red Hat. Подробнее о GNU/Linux и дистрибутивах можно прочитать и .

Возможно, у кого-то возник вопрос: почему GNU/Linux, а не просто Linux. Все дело в том, что Linux – это всего лишь ядро, в то время как GNU/Linux – это операционная система. Однако, Linux’ом можно называть как ядро так и ОС – и так и так будет правильно.

Условно говоря, ОС состоит из двух частей: kernel space и user space . Kernel space это ядро, которое непосредственно взаимодействует с устройствами в системе, обслуживает их и производит настройку. В нашем случае – это ядро Linux, разработка которого началась в 1991 году Линусом Торвальдсом, являвшимся на тот момент студентом. Оно поддерживает многозадачность, динамические библиотеки, виртуальную память, отложенную загрузку, большинство сетевых протоколов и производительную систему управления памятью и распространяется по лицензии GNU GPL, т.е. свободно. Подробнее про само ядро и его «увлекательную» систему нумерации версий можно узнать . Пользователи же работают в пространстве user space (пространстве приложений), а это в свою очередь файлы. Вообще говоря, все в Linux’е представлено файлами - настройки, сами приложения, даже процессы. Это очень удобно при настройке и когда пытаешься выяснить почему же все поломалось.

Дистрибутивы Linux распространяются в основном по лицензии GNU General Public License – лицензии на свободное программное обеспечение. Цель GNU GPL - предоставить пользователю права копировать, модифицировать и распространять (в том числе на коммерческой основе) программы, а также гарантировать, что и пользователи всех производных программ получат вышеперечисленные права.

Помимо выше указанных неоспоримых плюсов данной ОС, она обладает еще рядом особенностей:
1.Безопасность
2.Производительность
3.Надежность
4.Масштабируемость
5.Аппаратная совместимость
6.Не требуется импортозамещение
7.Зарплата Linux администраторов выше, чем у обычных администраторов

Благодаря выше перечисленным особенностям, Linux получил широкое распространение и используется во многих сферах: критические сервисы (скоростные поезда в Японии, CERN, системы контроля воздушного трафика), социальные сети, поисковые сервисы, а так же в мобильных телефонах, планшетах, ПК, банкоматах и автомобильной электронике.

Вообще говоря, на основе Linux можно сделать много чего, но мы остановимся на более повседневных вещах. Предположим, в некоторой компании, где работает большое количество пользователей, нужно развернуть серверную инфраструктуру, т.е. пользователям нужно дать доступ в Интернет, запретить в рабочее время сидеть в социальных сетях, организовать корпоративную почту, файловый сервер, и т.д. Что мы можем сделать на основе Linux? На самом деле очень даже многое.

Мы можем:
1.Настроить программный маршрутизатор/ шлюз доступа в Интернет с функциями межсетевого экрана и DHCP сервера
2.Ограничить доступ пользователей к сети Интернет с помощью proxy сервера
3.Организовать почтовый сервер для корпоративной почты
4.Создать веб сервер для корпоративного сайта и внутренних веб ресурсов
6.Настроить первичный и вторичный DNS сервера
7.Развернуть файловый сервер
8.Собирать резервные копии с остальных серверов
9.Развернуть сервер логирования для сбора событий с других серверов

Такую схему мы и будем разворачивать в рамках данного курса.

Полагаю, на этом первый урок можно закончить.