One place for hosting & domains

      для

      Использование SSH для подключения к удаленному серверу


      Введение

      Одним из важнейших инструментов в работе системного администратора является SSH.

      SSH, или Secure Shell, — это протокол, используемый для безопасного входа на удаленные системы. Это самый распространенный способ получения доступа к удаленным серверам Linux.

      В этом руководстве мы обсудим, как использовать SSH для подключения к удаленной системе.

      Базовый синтаксис

      Чтобы подключиться к удаленной системе с помощью SSH, мы будем использовать команду ssh. В самом базовом виде команда имеет следующую форму:

      remote_host в этом примере является IP-адресом или доменным именем узла, к которому вы пытаетесь подключиться.

      Эта команда предполагает, что ваше имя пользователя на удаленной системе совпадает с именем пользователя в локальной системе.

      Если ваше локальное имя пользователя отличается от имени пользователя в удаленной системе, вы можете задать его, используя следующий синтаксис:

      • ssh remote_username@remote_host

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

      Чтобы завершить сеанс ssh и вернуться в сеанс локальной оболочки, введите следующую команду:

      Как работает SSH?

      SSH выполняет подключение клиентской программы к серверу ssh с именем sshd.

      В предыдущем разделе команда ssh использовалась для вызова клиентской программы. Сервер ssh уже запущен на удаленном хосте remote_host, который мы указали.

      На вашем сервере должен быть запущен сервер sshd. Если это не так, вам может потребоваться подключение к серверу через веб-консоль или локальную последовательную консоль.

      Процесс запуска сервера ssh зависит от дистрибутива Linux, который вы используете.

      В Ubuntu вы можете запустить сервер ssh с помощью следующей команды:

      Эта команда должна запускать сервер sshd, после чего вы сможете выполнять удаленный вход.

      Настройка SSH

      При изменении конфигурации SSH вы меняете настройки сервера sshd.

      В Ubuntu основной файл конфигурации sshd находится в каталоге /etc/ssh/sshd_config.

      Выполните резервное копирование текущей версии этого файла перед началом редактирования:

      • sudo cp /etc/ssh/sshd_config{,.bak}

      Откройте файл в текстовом редакторе:

      • sudo nano /etc/ssh/sshd_config

      Скорее всего, вы захотите оставить большинство опций в этом файле без изменений. Однако существует несколько настроек, на которые вам стоит обратить особое внимание:

      /etc/ssh/sshd_config

      Port 22
      

      Объявление порта указывает, подключения к какому порту будет отслеживать сервер sshd. По умолчанию используется порт 22. Вам, скорее всего, не придется изменять данную настройку, если только у вас нет конкретных причин для иного решения. Если вы решите изменить порт, позже мы покажем, как подключиться к новому порту.

      /etc/ssh/sshd_config

      HostKey /etc/ssh/ssh_host_rsa_key
      HostKey /etc/ssh/ssh_host_dsa_key
      HostKey /etc/ssh/ssh_host_ecdsa_key
      

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

      /etc/ssh/sshd_config

      SyslogFacility AUTH
      LogLevel INFO
      

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

      Если вы сталкиваетесь с проблемами при работе с SSH, увеличение объема логируемых данных может быть хорошим решением, которое поможет понять, в чем заключается проблема.

      /etc/ssh/sshd_config

      LoginGraceTime 120
      PermitRootLogin yes
      StrictModes yes
      

      Эти параметры определяют некоторые данные для входа в систему.

      Опция LoginGraceTime определяет количество секунд, в течение которых следует сохранять подключение при отсутствии успешных попыток входа в систему.

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

      PermitRootLogin определяет, разрешен ли вход с помощью пользователя с правами root.

      В большинстве случаев необходимо изменить значение на no, если вы создали учетную запись пользователя, которая имеет доступ к высокому уровню привилегий (через su или sudo) и может использоваться для входа в систему через ssh.

      strictModes — это защитник, который будет препятствовать попыткам входа, если файлы аутентификации доступны для чтения всем.

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

      /etc/ssh/sshd_config

      X11Forwarding yes
      X11DisplayOffset 10
      

      Эти параметры используются для настройки такой возможности, как X11 Forwarding. X11 Forwarding позволяет просматривать графический пользовательский интерфейс (GUI) удаленной системы на локальной системе.

      Эта функция должна быть активирована на сервере и передана клиенту SSH во время подключения с помощью опции -X.

      После внесения изменений сохраните и закройте файл, введя CTRL+X, Y, а затем нажмите ENTER.

      Если вы внесли изменения в какие-либо настройки в файле /etc/ssh/sshd_config, необходимо перезапустить ваш сервер sshd, чтобы изменения вступили в силу:

      • sudo systemctl reload ssh

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

      Вы можете использовать несколько активных сеансов во время внесения изменений. Это позволит вам вернуться к первоначальной конфигурации, если это потребуется.

      Выполнение входа через SSH с использованием ключей

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

      Как работает аутентификация с помощью ключей?

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

      Приватный ключ располагается на клиентском компьютере, этот ключ защищен и хранится в секрете.

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

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

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

      Весь этот процесс выполняется в автоматическом режиме после того, как вы настроите ключи.

      Создание ключей SSH

      Ключи SSH необходимо генерировать на компьютере, откуда вы хотите войти в систему. Как правило, это ваш локальный компьютер.

      Введите следующую команду в командной строке:

      Нажмите ENTER, чтобы принять используемые по умолчанию значения. Ваши ключи будут сгенерированы в файлах ~/.ssh/id_rsa.pub и ~/.ssh/id_rsa.

      Перейдите в каталог .ssh с помощью следующей команды:

      Просмотрите данные о разрешениях для файлов:

      Output

      -rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys -rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa -rw-r--r-- 1 demo demo 396 Sep 9 23:13 id_rsa.pub

      Как вы можете видеть, файл id_rsa доступен для чтения и записи только владельцу. Именно такие разрешения позволяют сохранить его в секрете.

      В то же время файл id_rsa.pub может использоваться совместно и имеет соответствующие разрешения для данной деятельности.

      Как передать ваш публичный ключ на сервер

      Если в настоящее время вы используете доступ к серверу с помощью пароля, вы можете скопировать ваш публичный ключ на сервер, воспользовавшись данной командой:

      В результате будет создан сеанс SSH. Когда вы введете пароль, ваш публичный ключ будет скопирован в файл авторизованных ключей сервера, что позволит не использовать пароль при входе в следующий раз.

      Опции для клиентской стороны

      Существует ряд опциональных флагов, которые вы можете использовать при подключении через SSH.

      Некоторые из них могут быть необходимы при наличии определенных настроек конфигурации sshd на удаленном хосте.

      Например, если вы изменили номер порта в конфигурации sshd, вам потребуется указать этот порт на клиентской стороне с помощью следующей команды:

      • ssh -p port_number remote_host

      Если вы хотите выполнить отдельную команду на удаленной системе, вы можете указать ее после имени хоста следующим образом:

      • ssh remote_host command_to_run

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

      Как уже отмечалось ранее, если функция X11 forwarding активирована на обоих компьютерах, вы можете получить доступ к данному функционалу, воспользовавшись следующей командой:

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

      Отключение аутентификации по паролю

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

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

      Откройте файл конфигурации sshd, воспользовавшись пользователем root или пользователем с привилегиями sudo:

      • sudo nano /etc/ssh/sshd_config

      Найдите строку Password Authentication и раскомментируйте ее, удалив символ # в начале строки. Теперь вы можете указать значение no:

      /etc/ssh/sshd_config

      PasswordAuthentication no
      

      Вы должны также изменить значения двух других настроек (если вы не вносили изменения в этот файл ранее) — PubkeyAuthentication и ChallengeResponseAuthentication. Значения устанавливаются по умолчанию и выглядят следующим образом:

      /etc/ssh/sshd_config

      PubkeyAuthentication yes
      ChallengeResponseAuthentication no
      

      После внесения изменений сохраните и закройте файл.

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

      • sudo systemctl reload ssh

      Теперь аутентификация по паролю должна быть отключена, а ваш сервер должен быть доступен только с помощью аутентификации по ключу SSH.

      Заключение

      Обучение работе с SSH точно будет полезным, хотя бы потому, что это очень распространенный инструмент.

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



      Source link

      Использование Systemctl для управления службами и блоками Systemd


      Введение

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

      В этом руководстве мы обсудим команду systemctl, которая является инструментом центрального управления для контроля системы инициализации. Мы расскажем о том, как управлять службами, проверять статус, изменять состояние системы и работать с файлами конфигурации.

      Обратите внимание, что хотя система systemd стала системой инициализации по умолчанию для многих дистрибутивов Linux, она не используется повсеместно во всех дистрибутивах. По мере изучения этого руководства, если ваш терминал выводит ошибку bash: systemctl is not installed, скорее всего, на вашей машине установлена другая система инициализации.

      Управление службами

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

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

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

      Запуск и остановка служб

      Чтобы запустить службу systemd, используя инструкции в файле модуля службы, используйте команду start. Если вы работаете как пользователь без прав root, вам потребуется использовать sudo, поскольку это влияет на состояние операционной системы:

      • sudo systemctl start application.service

      Как мы уже упомянули выше, systemd будет искать файлы *.service для команд управления службами, так что команду можно легко ввести следующим образом:

      • sudo systemctl start application

      Хотя вы можете использовать вышеуказанный формат для общего администрирования, для ясности мы будем использовать суффикс .service для остальных команд, чтобы предельно четко выражать цель, над которой мы работаем.

      Чтобы остановить работающую в данный момент службу, можно использовать команду stop:

      • sudo systemctl stop application.service

      Перезапуск и перезагрузка

      Чтобы перезапустить работающую службу, можно использовать команду restart:

      • sudo systemctl restart application.service

      Если данное приложение может перезагрузить файлы конфигурации (без перезапуска), вы можете выдать команду reload для инициализации этого процесса:

      • sudo systemctl reload application.service

      Если вы не уверены, есть ли у службы функция перезагрузки своей конфигурации, можно использовать команду reload-or-restart. Это перезагрузит необходимую конфигурацию при наличии. В противном случае будет перезагружена служба для выбора новой конфигурации:

      • sudo systemctl reload-or-restart application.service

      Включение и отключение служб

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

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

      • sudo systemctl enable application.service

      При этом будет создана символическая ссылка из системной копии служебного файла (обычно в /lib/systemd/system или /etc/systemd/system) в месте на диске, где systemd ищет файлы для автозапуска (обычно /etc/systemd/system/some_target.target.wants; что такое цель, мы рассмотрим далее в этом руководстве).

      Чтобы отключить автоматический запуск службы, можно ввести следующее:

      • sudo systemctl disable application.service

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

      Помните, что включение службы не запустит ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, необходимо дать обе команды, start и enable.

      Проверка статуса служб

      Чтобы проверить статус службы в вашей системе, можно использовать команду status:

      • systemctl status application.service

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

      Например, при проверке статуса сервера Nginx вы можете видеть следующий вывод:

      Output

      ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

      Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий.

      Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду is-active:

      • systemctl is-active application.service

      Это вернет текущий статус модуля, который обычно active или inactive. Код выхода будет «0», если он активен, и результат будет проще парсить в скрипты оболочки.

      Чтобы увидеть, включен ли модуль, можно использовать команду is-enabled:

      • systemctl is-enabled application.service

      Это выведет информацию о том, что служба enabled или disabled, и снова установит код выхода на «0» или «1» в зависимости от вопроса команды.

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

      • systemctl is-failed application.service

      Это вернет active, если он работает должным образом, или failed, если возникла ошибка. Если модуль был намеренно остановлен, может вернуться unknown или inactive. Статус выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на какой-либо другой статус.

      Обзор состояния системы

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

      Список текущих модулей

      Чтобы увидеть список всех активных модулей, о которых знает systemd, можно использовать команду list-units:

      Это покажет вам список всех модулей, которые у systemd активны в системе. Результат будет выглядеть примерно так:

      Output

      UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System [email protected] loaded active running Getty on tty1 . . .

      Вывод содержит следующие столбцы:

      • UNIT: имя модуля systemd
      • LOAD: указывает на то, парсила ли systemd конфигурацию модуля. Конфигурация загруженных модулей сохраняется в памяти.
      • ACTIVE: краткое состояние активности модуля. Обычно это довольно стандартный способ сообщить, запущен модуль или нет.
      • SUB: это состояние более низкого уровня, которое указывает более подробную информацию о модуле. Это часто зависит от типа модуля, состояния и фактического метода работы модуля.
      • DESCRIPTION: краткое текстовое описание того, чем является модуль/что делает.

      Поскольку команда list-units показывает по умолчанию только активные модули, для всех вводов выше отобразится loaded в столбце LOAD и active в столбце ACTIVE. Это отображение фактически является поведением по умолчанию systemctl при вызове без дополнительных команд, поэтому вы увидите то же, что и при вызове systemctl без аргументов:

      Мы можем использовать systemctl для вывода различной информации путем добавления дополнительных флагов. Например, чтобы увидеть все модули, которые загрузила система systemd (или пыталась загрузить), независимо от их активности в данный момент, можно использовать следующий флаг --all:

      • systemctl list-units --all

      Это отобразит все модули, которые загрузила или пыталась загрузить система systemd независимо от текущего состояния системы. Некоторые модули становятся неактивными после работы, а некоторые модули, которые система systemd пыталась загрузить, могут не быть найдены на диске.

      Вы можете использовать другие флаги для фильтрации этих результатов. Например, мы можем использовать флаг --state= для указания состояния LOAD, ACTIVE или SUB, которое мы хотим увидеть. Вам потребуется сохранить флаг --all, чтобы systemctl позволила отображать неактивные модули:

      • systemctl list-units --all --state=inactive

      Другим распространенным фильтром является фильтр ---type=. Мы можем задать systemctl только для отображения модулей интересующего нас типа. Например, чтобы увидеть только активные модули службы, мы можем:

      • systemctl list-units --type=service

      Список все файлов модулей

      Команда list-units отображает только модули, которые система systemd пыталась парсить или загрузить в память. Поскольку systemd будет считывать только те модули, которые считает необходимыми, это необязательно будут все модули, доступные в системе. Чтобы увидеть все доступные файлы модулей в путях systemd, включая те, что система systemd пыталась загрузить, можно использовать команду list-unit-files:

      • systemctl list-unit-files

      Модули являются представлениями ресурсов, о которых знает systemd. Поскольку система systemd необязательно считывала все определения модуля в этом виде, она представляет информацию только о самих файлах. Вывод содержит два столбца: файл модуля и состояние.

      Output

      UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . .

      Состояние будет, как правило, enabled, disabled, static или masked. В этом контексте static обозначает, что файл модуля не содержит раздел install, который используется для включения модуля. Эти модули как таковые не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость другого модуля и не должен работать самостоятельно.

      Мы рассмотрим сразу же, что означает masked.

      Управление модулями

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

      Отображение файла модуля

      Чтобы отобразить файл модуля, который система systemd загрузила в систему, можно использовать команду cat (она была добавлена в версию systemd 209). Например, чтобы увидеть файл модуля демона-планировщика atd, можно ввести следующее:

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      Вывод — это файл модуля, известный выполняемому в настоящее время процессу systemd. Это может быть важно, если вы недавно модифицировали файлы модуля или если вы переопределяете определенные опции во фрагменте файла модуля (мы рассмотрим это позже).

      Отображение зависимостей

      Чтобы увидеть дерево зависимостей модуля, можно использовать команду list-dependencies:

      • systemctl list-dependencies sshd.service

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

      Output

      sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . .

      Рекурсивные зависимости отображаются только для модулей .target, которые указывают состояние системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг --all.

      Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флаг --reverse. Другие полезные флаги --before и --after могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно, перед ними и после.

      Проверка свойств модуля

      Чтобы увидеть свойства более низкого уровня модуля, можно использовать команду show. При этом будет выведен список свойств, заданных для указанного модуля с помощью формата key=value:

      • systemctl show sshd.service

      Output

      Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . . .

      Если вы хотите отобразить одно свойство, можно передать флаг -p с именем свойства. Например, чтобы увидеть конфликты, которые есть у модуля sshd.service, можно ввести следующее:

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Маскировка и снятие маскировки модулей

      В разделе управления службами мы узнали, как остановить или отключить службу, но systemd также имеет возможность отметить модуль как полностью незапускаемый, автоматически или вручную, связав его с /dev/null. Это называется маскировкой модуля, и она возможна с помощью команды mask:

      • sudo systemctl mask nginx.service

      Это не позволит запустить службу Nginx автоматически или вручную, пока она замаскирована.

      Если вы проверите list-unit-files, вы увидите, что служба теперь указана как замаскированная:

      • systemctl list-unit-files

      Output

      . . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . .

      Если вы попытаетесь запустить службу, вы увидите следующее сообщение:

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Чтобы снять маскировку модуля и сделать его доступным для использования снова, используйте команду unmask:

      • sudo systemctl unmask nginx.service

      Это вернет модуль в его предыдущее состояние, что позволит его запускать или включать.

      Редактирование файлов модулей

      Хотя конкретный формат файлов модулей выходит за рамки этого руководства, systemctl предоставляет встроенные механизмы для редактирования и модификации файлов модулей при необходимости изменений. Эта функция добавлена в версию systemd 218.

      Команда edit по умолчанию откроет фрагмент файла модуля для интересующего модуля:

      • sudo systemctl edit nginx.service

      Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение модуля. Каталог будет создан в каталоге /etc/systemd/system, который содержит название модуля с добавлением .d. Например, для nginx.service будет создан каталог под названием nginx.service.d.

      В этом каталоге будет создан фрагмент под названием override.conf. При загрузке модуля systemd в памяти соединит фрагмент переопределения с полным файлом модуля. Директивы фрагмента получат приоритет над найденными в оригинальном файле модуля.

      Если вы хотите редактировать весь файл модуля, а не создавать фрагмент, можно передать флаг --full:

      • sudo systemctl edit --full nginx.service

      Это загрузит текущий файл модуля в редактор, где его можно редактировать. После выхода из редактора измененный файл будет записан в /etc/systemd/system, что будет иметь приоритет над определением модуля системы (обычно находится где-то в /lib/systemd/system).

      Чтобы удалить какие-либо сделанные добавления, удалите либо каталог конфигурации модуля .d или модифицированный служебный файл из /etc/systemd/system. Например, для удаления фрагмента можно ввести следующее:

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Чтобы удалить весь отредактированный файл модуля, добавим:

      • sudo rm /etc/systemd/system/nginx.service

      После удаления файла или каталога необходимо перезагрузить процесс systemd, чтобы он больше не пытался ссылаться на эти файлы и не возвращался к использованию системных копий. Для этого можно ввести следующую команду:

      • sudo systemctl daemon-reload

      Настройка состояния системы (уровень запуска) с помощью целей

      Целями являются специальные файлы модулей, которые описывают состояние системы или точку синхронизации. Как и другие модули, файлы, которые определяют цели, могут быть идентифицированы по суффиксу, которым в данном случае является .target. Цели сами по себе немного значат, а используются для группировки других модулей.

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

      Например, swap.target используется для указания того, что переключение готово к использованию. Модули, являющиеся частью этого процесса, могут синхронизироваться с этой целью путем указания в своей конфигурации, что они WantedBy= или RequiredBy= swap.target. Модули, которым требуется возможность переключения, могут указывать это состояние с помощью спецификаций Wants=, Requires= и After= для указания характера их отношений.

      Получение и настройка цели по умолчанию

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

      Output

      multi-user.target

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

      • sudo systemctl set-default graphical.target

      Список доступных целей

      Вы можете получить список имеющихся целей в вашей системе, введя:

      • systemctl list-unit-files --type=target

      В отличие от уровней запуска, несколько целей могут быть активны одновременно. Активная цель указывает, что система systemd попыталась запустить все модули, привязанные к цели, и не попыталась закрыть их снова. Чтобы увидеть все активные цели, введите:

      • systemctl list-units --type=target

      Изолирование целей

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

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

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

      • systemctl list-dependencies multi-user.target

      Если вы удовлетворены модулями, которые будут сохранены в активном состоянии, можно изолировать цель, введя:

      • sudo systemctl isolate multi-user.target

      Использование комбинации быстрого ввода для важных событий

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

      Например, чтобы перевести систему в режим спасения (один пользователь), можно использовать команду rescue вместо isolate rescue.target:

      Это обеспечит дополнительную функцию предупреждения всех подключенных пользователей о событии.

      Чтобы остановить систему, можно использовать команду halt:

      Для инициализации полного отключения можно использовать команду poweroff:

      Перезапуск можно начать с помощью команды reboot:

      Все это оповестит подключенных пользователей о том, что происходит событие, что-то, что только выполняет или изолирует цель, не сработает. Обратите внимание, что большинство машин будет привязывать более короткие, более традиционные команды для этих операций, чтобы правильно работать с systemd.

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

      Заключение

      К этому моменту вы должны уже ознакомиться с некоторыми базовыми возможностями команды systemctl, которая позволяет взаимодействовать и контролировать экземпляр systemd. Утилита systemctl будет главной точкой взаимодействия для управления службами и состоянием системы.

      Хотя systemctl работает главным образом с основным процессом systemd, в экосистеме systemd есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и сеансы пользователя, обрабатываются отдельными демонами и утилитами управления (journald/journalctl и logind/loginctl соответственно). Знакомство с этими другими инструментами и демонами упростит задачу управления.



      Source link

      Используйте ViewChild в Angular для доступа к дочернему компоненту, директиве или элементу DOM


      Введение

      В этой статье мы познакомим вас с декоратором Angular ViewChild.

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

      Использование ViewChild с директивами

      ViewChild открывает возможность доступа к директивам.

      Допустим, у нас имеется директива SharkDirective.

      В идеале мы используем @angular/cli для генерирования директивы:

      • ng generate directive shark

      В противном случае необходимо добавить ее вручную в app.module.ts:

      app.module.ts

      import { SharkDirective } from './shark.directive';
      ...
      @NgModule({
        declarations: [
          AppComponent,
          SharkDirective
        ],
        ...
      })
      

      Наша директива будет искать элементы с атрибутом appShark и добавлять в начало текста элемента слово Shark:

      shark.directive.ts

      import {
        Directive,
        ElementRef,
        Renderer2
      } from '@angular/core';
      
      @Directive(
        { selector: '[appShark]' }
      )
      export class SharkDirective {
        creature="Dolphin";
      
        constructor(elem: ElementRef, renderer: Renderer2) {
          let shark = renderer.createText('Shark ');
          renderer.appendChild(elem.nativeElement, shark);
        }
      }
      

      Затем мы добавим Shark в Fin, используя его в шаблоне компонента:

      app.component.html

      <span appShark>Fin!</span>
      

      При просмотре приложения в браузере оно будет выглядеть так:

      Output

      Shark Fin!

      Теперь мы можем получить доступ к переменной экземпляра creature директивы SharkDirective и задать переменную экземпляра extraCreature с ее значением:

      app.component.ts

      import {
        Component,
        ViewChild,
        AfterViewInit
      } from '@angular/core';
      import { SharkDirective } from './shark.directive';
      
      @Component({
        selector: 'app-root',
        templateUrl: './app.component.html',
        styleUrls: ['./app.component.css']
      })
      export class AppComponent implements AfterViewInit {
        extraCreature: string;
      
        @ViewChild(SharkDirective)
        set appShark(directive: SharkDirective) {
          this.extraCreature = directive.creature;
        };
      
        ngAfterViewInit() {
          console.log(this.extraCreature); // Dolphin
        }
      }
      

      Здесь мы использовали задающий метод, чтобы задать переменную extraCreature. Обратите внимание, что мы ждем, пока блок жизненного цикла AfterViewInit не получит доступ к нашей переменной, поскольку тогда станут доступными дочерние компоненты и директивы.

      При просмотре приложения в браузере мы видим "Shark Fin!", сообщение. Однако в журнале консоли отображается следующее:

      Output

      Dolphin

      Родительскому компоненту удалось получить доступ к значению из директивы.

      Использование ViewChild с элементами DOM

      ViewChild предоставляет возможность доступа к элементам модели DOM, имеющим шаблонную переменную.

      Допустим в нашем шаблоне имеется <input> с шаблонной переменной #someInput:

      app.component.html

      <input #someInput placeholder="Your favorite sea creature">
      

      Теперь мы можем получить доступ к <input> с помощью ViewChild и задать значение:

      app.component.ts

      import {
        Component,
        ViewChild,
        AfterViewInit,
        ElementRef
      } from '@angular/core';
      
      @Component({
        selector: 'app-root',
        templateUrl: './app.component.html',
        styleUrls: ['./app.component.css']
      })
      export class AppComponent implements AfterViewInit {
        @ViewChild('someInput') someInput: ElementRef;
        ngAfterViewInit() {
          this.someInput.nativeElement.value="Whale!";
        }
      }
      

      Когда срабатывает ngAfterViewInit, для <input> задается следующее значение:

      Output

      Whale!

      Родительскому компоненту удалось задать значение дочернего элемента DOM.

      Использование ViewChild с дочерними компонентами

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

      Допустим, у нас имеется компонент ChildComponent. В идеале мы используем @angular/cli для генерирования компонента:

      • ng generate component child --flat

      В противном случае вам может понадобиться создать файлы child.component.css и child.component.html и вручную добавить их в app.module.ts:

      app.module.ts

      import { ChildComponent } from './child.component';
      ...
      @NgModule({
        declarations: [
          AppComponent,
          ChildComponent
        ],
        ...
      })
      

      Мы добавим метод whoAmI в компонент ChildComponent, который возвращает следующее сообщение:

      child.component.ts

      whoAmI() {
        return 'I am a child component!';
      }
      

      Далее мы разместим ссылку на компонент в нашем шаблоне приложения:

      app.component.html

      <app-child>child works!</app-child>
      

      Теперь мы можем вызвать метод whoAmI внутри класса родительского компонента с помощью ViewChild, как показано здесь:

      app.component.ts

      import {
        Component,
        ViewChild,
        AfterViewInit
      } from '@angular/core';
      import { ChildComponent } from './child.component';
      
      @Component({
        selector: 'app-root',
        templateUrl: './app.component.html',
        styleUrls: ['./app.component.css'],
      })
      export class AppComponent implements AfterViewInit {
        @ViewChild(ChildComponent) child: ChildComponent;
        ngAfterViewInit() {
          console.log(this.child.whoAmI()); // I am a child component!
        }
      }
      

      При просмотре приложения в браузере отображается журнал консоли:

      Output

      I am a child component!

      Родительскому компоненту удалось вызвать метод whoAmI дочернего компонента.

      Заключение

      Вы научились использовать ViewChild для доступа к директиве, дочернему компоненту и элементу DOM из класса родительского компонента.

      Если шаблон динамически изменится на новый элемент, ViewChild автоматически обновит шаблон.

      Если вам требуется доступ к нескольким дочерним элементам, вам следует использовать метод ViewChildren.

      Если вы хотите узнать больше об Angular, посмотрите нашу страницу тем по Angular, где вы найдете упражнения и проекты по программированию.



      Source link