ServerAdmin.ru
31.3K subscribers
664 photos
55 videos
22 files
2.86K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Регистрация в РКН: https://vk.cc/cG1Urj
Download Telegram
Посоветую вам один полезный ресурс, который содержит информацию на тему поиска работы, собеседований, резюме:

https://easyoffer.ru

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

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

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

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

#обучение
👍105👎10
Я в разное время обозревал наиболее популярные продукты для упрощения установки ОС на железо или виртуальные машины с помощью создания универсальных загрузочных флешек или образов для установки по сети или через интернет. Вот о чём я писал:

◽️Ventoy - создание флешки с набором образов ОС
◽️YUMI – Multiboot USB Creator - аналог ventoy
◽️netboot.xyz - универсальный образ для установки систем через интернет
◽️FOG Project - PXE или TFTP сервер с веб интерфейсом
◽️Cobbler - PXE + DHCP + DNS сервер. Более функциональный аналог FOG.
◽️MAAS - PXE сервер от авторов Ubuntu, расшифровывается как Metal-As-A-Service.

Для полноты картины не хватало одного продукта, до которого всё не доходили руки - iVentoy. Это промежуточный вариант между масштабными системами автоматической раскатки систем типа Cobbler и MAAS и локальным Ventoy. То есть это Ventoy с установкой систем по сети с помощью технологии PXE. Устанавливается и настраивается максимально просто. Не нужно долго разбираться, изучать и настраивать. Просто берёшь и запускаешь. Покажу как он работает.

Для примера возьму в качестве хостовой системы, где будет запущен PXE сервер, Windows. Также есть версия под Linux. Для установки системы из ISO образа по сети нужно:

1️⃣ Скачать из репозитория архив с программой iventoy-1.0.20-win64-free.zip.
2️⃣ Распаковать программу. В директорию iso скопировать набор образов, которые вы хотите использовать в качестве загрузочных. Я пробовал и с Linux, и с Windows.
3️⃣ Запустить программу. Автоматически откроется браузер с веб интерфейсом по адресу 127.0.0.1:26000.
4️⃣ Настраиваете либо локальный DHCP сервер, который входит в состав iventoy, либо на своём внешнем указываете в качестве PXE сервера IP адрес машины, где запускаете iventoy. Сам iventoy может выступать в качестве простого DHCP сервера. Достаточно указать в его настройках основные параметры - диапазон IP адресов, адрес шлюза и DNS сервера.
5️⃣ Если используете свой текущий DHCP сервер, то вам необходимо настроить параметр Next Server или 066 DHCP Option и Bootfile Name или 067 DHCP Option. Просто укажите IP адрес машины с iventoy и имя файла. В Mikrotik, в настройках DHCP параметр так и называется - Next Server. А с Bootfile есть один нюанс, связанный с использованием режимов Legacy BIOS и UEFI. Я не буду пересказывать инструкцию, а просто покажу, где и как этот вопрос решается. Там относительно просто, надо только выбрать тот режим, что вам больше подходит. iVentoy умеет отрабатывать оба этих режима, secure boot не поддерживает.
6️⃣ Запускаете клиентскую машину и выбираете там загрузку по сети. Где-то может быть отдельный параметр в BIOS, который разрешает использовать PXE для загрузки.
7️⃣ Запускаете машину, выбираете один из загруженных ранее образов в iso папку и устанавливаете систему.

Я попробовал работу только с виртуальными машинами. Нормально установилась и система с Windows, и с Linux.

iVentoy максимально простая система из всех подобных. Нет никаких особых настроек и возможностей. Просто запуск установки из списка загруженных образов ISO. А в них уже можете сами настраивать всё, что вам нужно.

🌐 Сайт / Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#pxe
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍223👎4
2025-01-19_215325.png
4.5 MB
Вчера себе сделал обоину на рабочий стол. Может кому-то пригодится, либо просто идея понравится. Я уже пару лет себе делаю обои на рабочий стол с календарём. По мне, так это очень удобно. Дополнительно добавил правописание метрик, так как постоянно путаю прописные и заглавные буквы. Если не перепроверю, обязательно с ошибкой напишу.

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

А вы как думаете, что ещё пригодилось бы на рабочем столе? Иногда простые советы или комментарии потом сильно упрощают жизнь. Я кое-что неизменно беру на вооружение. Было время, всякие системные метрики выносил, но они только отвлекают. Реальной необходимости в них нет. В трее есть текущая частота и температура процессора. К сожалению, на ноутах Thinkpad это необходимая информация.

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

Ну и раз уж такая тема зашла упомяну ещё одну вещь. Я когда обсуждал свой новый моник 27" 2К меня прям чуть ли не унизили тем, какой я старый и отсталый, работаю с одним моником, да ещё таким маленьким. Типа надо было брать либо здоровый, либо хотя бы 2. В конце года читал интересный отчёт небезызвестного Вастрика, где он рассказывал, как себе монитор выбирал. Он там тоже всякие варианты пробовал, но остановился на одном 32" мониторе. У него стол глубокий, так что взял 32", а так тоже к 27" примерялся.

На днях на эту же тему со знакомым айтишником общался, он мне тоже сказал, что ему подходит максимум 27" 2К, а больше всего нравится на 24 FullHD работать. Я теперь хоть успокоился. Сам работаю за 23.8" 1920x1200. Не надо никакие окна подгонять, масштабы менять. Мне для работы это идеальный размер. Ноут рядом лежит, но даже не раскрываю его. Второй экран не нужен.

Слаб я ещё в плане мнения окружающих. Требуется внешнее подтверждение адекватности, а то грустно становится. Не молодею же. Правда оба описанных примера тоже ~40 лет от роду 😂.

#разное
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍158👎10
При использование популярной в Linux утилиты ps чаще всего оперируешь PID процесса или грепаешь вывод по строке в имени процесса:

# ps -p 524 -o %mem,%cpu,cmd
# ps ax | grep prometheus

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

# ps -T -C prometheus
  PID  SPID TTY     TIME CMD
  525   525 ?    00:55:34 prometheus
  525   803 ?    00:03:10 prometheus
  525   808 ?    00:09:22 prometheus
  525  1054 ?    00:08:44 prometheus
  525  1113 ?    00:12:03 prometheus
  525  1129 ?    00:10:42 prometheus
  525  58983 ?    00:11:30 prometheus

Увидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:

# ps -T -C zabbix_server | wc -l
82

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

# ps ax | grep zabbix_server | wc -l
59

Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.

# ps -L -o spid,%mem,%cpu,cmd 508
SPID %MEM %CPU CMD
  1070 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1071 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1072 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1074 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1075 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
  1077 0.6 0.3 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

У Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:

# cat /proc/508/task/1077/stat
1077 (f2b/f.wp-login) ...................................

Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет status:

# cat /proc/508/task/1077/status

Ещё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:

# strace -p 1077

Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ -o:

# strace -p 1077 -o ~/strace.out

Можно конкретизировать, что записывать. Например, для Fail2ban будут актуальны операции открытия файлов и чтения:

# strace -p 1077 -e trace=openat,read

А для каких-то процессов будет иметь смысл следить за записью:

# strace -p 1077 -e trace=write

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

Трейсы в режиме реального времени можно посмотреть и в htop. Выбираете нужный процесс или поток и нажимайте s. Если strace установлена в системе, то увидите её работу.

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

📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #terminal #perfomance
15👍194👎2
Вчера одной знакомой мошенники взломали учётную запись от Госуслуг. Причём сделали это таким запутанным способом, что я даже не уверен, что ломали именно их. Расскажу обо всём по порядку. Возможно кто-то с подобным сталкивался. Другим наука будет, чтобы предупредили знакомых и родственников.

1️⃣ 9 утра, человек едет в метро. Раздаётся звонок на телефон. Слышно плохо. Мошенники называют ФИО и адрес проживания. Говорят, что пришла посылка на почту рядом с домом. Чтобы забрать, надо привязать в почте свой номер телефона, на который придёт код подтверждения для забора посылки.

2️⃣ Приходит смс от Госуслуг. Тут первая странность. В смс текст: Для подтверждения смены номера введите код подтверждения: 1234. Не сообщайте никому! Странности тут две. Во-первых, коды подтверждения у Госуслуг 6-ти значные, а тут только 4 знака. Во-вторых, сейчас от Госуслуг приходит другой текст. В конце добавляют, что этот код спрашивают только мошенники. И при этом смс пришла от отправителя gosuslugi и легла в тот же чат, где все остальные смс от реального сервиса.

3️⃣ Человек называет код и тут же понимает, что это какая-то ерунда и обман. Она кладёт трубку, заходит через приложение Госуслуг на смартфоне и меняет пароль. Приходит смс для аутентификации и там 6 знаков и привычный текст.

4️⃣ Человек заходит в свою почту и там видит несколько подозрительных писем:
▪️Первое от реальных Госуслуг, где указано, что её номер введён в другой учётной записи.
▪️Второе фейковое от хостинга Aeza, отправленное с домена aeza_email, где указано, что для подтверждения почты нужно пройти по ссылке и активировать учётку. Тут я уже удивился, так как сначала вообще не понял, при чём тут Aeza. В письме странные ссылки через сокращатели. Не ходил по ним. Письмо точно фейк, потому что у меня есть письма от реальной Аезы. Они по-другому отправляют.
▪️Третье письмо подделано под шаблон Госуслуг. Там сказано, что кто-то совершил вход под вашей учётной записью. Указан IP адрес и расположение: Украина - г. Киев. И ниже указан номер тех. поддержки, куда предлагают позвонить, если это были не вы. Забегая вперёд скажу, что номер мошенников. Письмо отправлено с домена в зоне .org, похожего на госуслуги.

5️⃣ Человек звонит по этому номеру. Там сразу снимают трубку, как-будто ждали звонка. Мужчина без всякого акцента рассказал, что кто-то заходил в учётку, если это не вы, то надо срочно менять пароль и привязку телефона. А потом отложил трубку и судя по всему забыл отключить микрофон. Начал разговаривать матерясь с какой-то девушкой рядом, а та ему говорила, что надо что-то ещё, чтобы она сделала или ничего не получится.

6️⃣ Знакомая поняла, что это опять мошенники, положила трубку. Зашла с компьютера в Госуслуги, снова сменила пароль, убедилась, что привязан её мобильный номер. Для аутентификации все смски с кодами приходили к ней на смартфон.

Всё просмотрела в личном кабинете, вроде никаких изменений. В списке действий ровно одно подозрительное действие как раз после первого звонка, совершённое не с её IP адреса. При этом IP адрес московский. Выполнено действие - отключение входа с подтверждением. Что это значит, не очень понятно, так как подтверждение по телефону реально не отключили.

Вот такая странная история произошла. Ниже список писем в тот день и скрины фейкового письма с госуслуг и от Aeza. Вот последняя меня больше всего интересует. При чём тут вообще этот хостинг? Знакомая с ним никак не связана и вообще не знает, что это такое.

И второй момент. От чего в итоге был передан мошенникам код из 4-х знаков? У меня есть подозрение, что Госуслуги тут только прикрытие каких-то других дел. Я не знаю, можно ли подделать отправителя смс, чтобы его сообщение попало в папку или чат с реальными смс от Госуслуг. А может на смену номера там только 4 символа и остался старый шаблон. Но смена по какой-то причине не состоялась.

Кто-нибудь сталкивался с подобным? Что это может быть? Какая-то многоходовая махинация. Тут и посылка, и фейковые письма, и поддержка.

#security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍133👎4
Если у вас стоит задача собрать небольшое количество текстовых логов в одном месте, то городить современные решения типа Loki, ELK, Graylog избыточно. Это и долго, и разбираться надо, если не умеешь, и по ресурсам затратно. Предлагаю старую, простую и проверенную временем альтернативу - syslog-ng. Я этот софт давно знаю и использую по мере необходимости.

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

# apt install syslog-ng

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

Открываем конфигурацию /etc/syslog-ng/syslog-ng.conf и добавляем один параметр, который позволит принимать логи по сети от других устройств и систем:

source s_net { udp(ip(0.0.0.0) port(514)); };

Можно выбрать любой IP адрес сервера, порт и протокол. Я указал стандартный порт UDP 514 для протокола syslog. Никто не мешает использовать что-то другое. Например TCP 1000:

source s_net { TCP(ip(0.0.0.0) port(1000)); };

Переходим в папку /etc/syslog-ng/conf.d и создаём там конфиг для приёма логов, например, с Mikrotik:

destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };
filter f_mikrotik { netmask("10.20.1.20/255.255.255.255"); };
log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };

Файл назвал mikrotik.conf. В syslog-ng объектный принцип описания конфигурации. Этот как раз то, почему я предпочитаю для таких задач использовать именно его, а не rsyslog. У последнего не такой удобный формат конфигурации.

Я создал объект d_mikrotik, который указывает на хранение логов в файле /var/log/_remote/mikrotik.log. Далее я сделал фильтр f_mikrotik, где указал в качестве условия IP адрес роутера. Можно и всю подсеть добавить. И в завершении указал, как именно будем логировать. Берём источник s_net, то есть всё, что приходит на UDP 514, проверяем по фильтру f_mikrotik и пишем в d_mikrotik, то есть в указанный лог-файл.

С таким подходом удобно настраивать что, куда и по каким условиям писать. Можно несколько source указать с разными интерфейсами, протоколами и портами. Если у вас устройства разнесены по разным подсетям, то можно описать приём в два разных лог-файла логи от Mikrotik и от Linux систем:

destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };
filter f_mikrotik { netmask("10.20.1.0/255.255.255.0"); };
log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };

destination d_linux { file("/var/log/_remote/linux.log"); };
filter f_linux { netmask("10.30.1.0/255.255.255.0"); };
log { source(s_net); filter(f_linux); destination(d_linux); };

По умолчанию syslog-ng работает от root, что не очень разумно и в данной задаче не нужно. Запустим его от пользователя syslog. Если вас это не беспокоит, то можно запускать и под root.

# useradd syslog -s /usr/sbin/nologin
# chown syslog /var/lib/syslog-ng /var/log/_remote

Добавляем в /etc/default/syslog-ng:

SYSLOGNG_OPTS="-u syslog -g syslog"
if [ ! -e /var/lib/syslog-ng.pid ] then
  touch /var/lib/syslog-ng.pid
fi
chown syslog /var/lib/syslog-ng.pid
chmod 0664 /var/lib/syslog-ng.pid

В файле /etc/syslog-ng/syslog-ng.conf меняем пользователя в параметрах:

owner("root"); group("adm")

на

owner("syslog"); group("syslog")

Идём на конечное устройство настраивать отправку логов. В Mikrotik это делается в System ⇨ Logging ⇨ Actions. В remote указываете IP адрес сервера с syslog-ng.

В системах Linux с rsyslog достаточно в /etc/rsyslog.conf добавить параметр:

*.* @10.20.1.5

и перезапустить его.

Получилось очень простое решение по централизованному сбору логов без аналитики, которое настраивается за 10 минут и не требует практически никаких особых ресурсов. На чём можно запустить Debian, там и будет работать.

Для просмотра логов через браузер можно использовать tailon, logdy, cockpit, webmin.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#logs #syslog
4👍151👎4
Расскажу об одной банальной вещи. Возможно кому-то она поможет, если в голову не приходило такое решение.

Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.

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

В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.

Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.

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

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

#network #backup
1👍104👎3
Изучал на днях один инструмент и случайно наткнулся на информацию про Systemd.path - триггер на события в файловой системе. Удивился, что не знаком с этой функциональностью. Либо уже забыл это. Но сам точно не использовал. С помощью Systemd.path можно отслеживать изменения в файловой системе и выполнять какие-то действия на их основе.

Функциональность очень полезная. Сразу покажу на примере. Допустим, нам надо выполнить какое-то действие при изменении файла. Настраиваем сначала слежение за файлом. Создаём файл /etc/systemd/system/daemon.path:

[Unit]
Description=Watch /etc/daemon/daemon.conf for changes

[Path]
PathModified=/etc/daemon/daemon.conf

[Install]
WantedBy=multi-user.target

Будем следить за изменением файла daemon.conf. А если оно случится, перезапустим службу daemon.service. Для этого создаём саму службу в файле /etc/systemd/system/daemon.service:

[Unit]
Description=Restart Daemon Service
After=network.target

[Service]
Type=oneshot
ExecStart=sh -c "/usr/bin/echo daemon service restarted at `date` >> /etc/daemon/restart.date"

[Install]
RequiredBy=daemon.path

Для теста и понимания, как это работает, настроил простейшее действие. Команда echo будет писать текущую дату перезапуска службы в файл /etc/daemon/restart.date. Запускаем проверку и саму службу:

# systemctl enable daemon.{path,service}
# systemctl start daemon.{path,service}

Убеждаемся, что первое выполнение службы было сделано в момент старта:

# systemctl status daemon.service

Должен был создаться файл /etc/daemon/restart.date. Теперь изменяем файл /etc/daemon/daemon.conf и проверяем снова restart.date. Там должна появиться новая строка с текстом daemon service restarted at и текущее время с датой.

Такой вот простой и удобный механизм. В строку ExecStart вместо echo можно указать любую команду или скрипт. Можете какую-то службу перезапускать или копировать куда-то файл при его изменении. Например, изменился TLS сертификат, можно его скопировать куда-то или перезапустить службу, которая его использует. Удобство тут в том, что всё логируется в systemd. И если у вас логи уже где-то хранятся и анализируются, то все события с path и service поедут туда автоматически и не надо отдельно об этом беспокоиться.

В данном примере я использовал директиву слежения за записью в файл PathModified. Помимо неё есть другие:

◽️PathExists= реагирует на появление заданного файла или директории.
◽️PathExistsGlob= то же самое что и предыдущее, но можно использовать маски для имён.
◽️PathChanged= отличается от PathModified тем, что реагирует не на запись в файл, а на закрытие файла после записи.
◽️DirectoryNotEmpty= реагирует на появление файла в пустой директории.

📌 Другая полезная (и не очень) функциональность SystemD:

◽️Systemd timers как замена Cron
◽️Journald как замена Syslog
◽️Systemd-journal-remote - централизованное хранение логов
◽️Systemd-journal-gatewayd - просмотр логов через браузер
◽️Hostnamectl для просмотра информации о системе
◽️Systemd-resolved - кэширующий DNS сервер
◽️Параметры Systemd для приоритизации дисковых операций
◽️Ограничение потребления памяти с Systemd
◽️Синхронизация времени с помощью systemd-timesyncd

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#systemd
2👍238👎5