Системное администрирование

Итак, у вас есть буханка ржаного хлеба, духовка и задача развернуть сервер с поддержкой DHCP и DNS? Это слышать как серьезная миссия, но мы возьмемся за нее со всей серьезностью.

Ингредиенты:

- 1 буханка ржаного хлеба

- 1 компьютер с возможностью установки серверных приложений

- 1 духовка

- порция веселого настроения

Инструкция:

Шаг 1: Создание сервера на буханке ржаного хлеба

Начнем с самого главного – наш серверный хлеб! Возьмите буханку ржаного хлеба, и осторожно обрежьте верхнюю часть. Затем аккуратно выньте сердцевину, чтобы освободить место для будущего сервера. Это будет ваш «корпус» сервера. Сейчас самое время для фантазии – вырежьте отверстия для вентиляции и разъемов для подключения. После того, как вы проделали все это, пришло время украсить ваш сервер. Вот именно, у вас создан уникальный сервер на ржаном хлебе!

Шаг 2: Подготовка духовки для развертывания

Теперь, когда у вас великолепно выглядящий сервер, давайте поговорим о том, как создать поддержку DHCP и DNS. Предварительно разогрейте вашу духовку до 180 градусов.

Шаг 3: Установка DHCP и DNS

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

Как только ваша "платформа" наберется сил, приступайте к установке приложений. Начнем с подключения DHCP: этот этап будет сложнее. Возьмите масло – оно поможет соединить устройства в сети. А теперь к делу: налейте его на сервер – не стесняйтесь, можно даже щедро. Теперь приступаем к установке DNS. Здесь нам понадобится немного сахара – вот это сладко! Посыпьте его сверху сервера и равномерно распределите по поверхности. Поставьте сервер обратно в духовку на 15 минут, чтобы установленные приложения пропеклись и полностью впитались.

И вот ваш сервер на ржаном хлебе готов к использованию с поддержкой DNS и DHCP! Готовы ли вы к этому? Надеемся, ваш ответ будет - да!

Наслаждайтесь результатом вашего непростого труда, и да помогут вам все серверные боги!

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

Тестовая инфраструктура, на которой будем воспроизводить проблемы состоит из виртуалки с Ubuntu 20.04, с установленным стеком LAMP и корневым разделом на 5гигов (потому что больше не понадобится).

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

После оповещения от мониторинга ваша задача первым делом подключиться к серверу по SSH и запустить несколько утилит, для проверки общего состояния сервера: uptime, free, ss, ps и т.д.

Удалённые файлы

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

Чтобы уменьшить количество выводимых данных (например чтобы убрать из вывода tmpfs или squashfs), применим опцию "-x" к df:

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

У du тоже есть полезная опция "-x", здесь она выполняет задачу исключения из вывода точек монтирования других файловых систем.

Общее пространство, занимаемое корневым разделом, составляет 4,2Gb. То есть у нас должно быть примерно 700Mb свободного места (15% от общего объема). Давайте перепроверим:

Всё так же. Значения в выводах df и du не совпадают:

Выглядит довольно запутанно. Объем свободного дискового пространства, сообщаемый df, меньше суммы размеров всех файлов. Чем же тогда занято всё место?
Оно занято удалёнными файлами.

В выводе команды lsof выше мы можем видеть, что логи сервера Apache хоть и были удалены, но всё еще заняты процессом (М.Керриск - Linux API исчерпывающее руководство, стр. 379). Особенно часто это происходит из-за неправильно настроенного logrotate. Иногда logrotate удаляет журнал, не сообщая процессу, что ему необходимо закрыть файловый дескриптор. Мы можем получить доступ к данным через /proc/$PID/fd/$DESCRIPTOR_NUMBER:

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

Есть пара возможных вариантов решения:

1. Вы можете перезапустить сервис, и дескриптор будет освобождён.

2. Или усечь длину файла до нуля, с помощью truncate:

Проверяем:

Отлично. Проблема решена.

Заключение

• Процесс (в нашем случае Apache) вызвал системный вызов open, и получил дескриптор файла для работы с ним. Поскольку это файл журнала, он не был закрыт сразу.

• Тем временем какой-то другой процесс (или тот же самый) пытался удалить файл (вызвал системный вызов unlink).

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

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

• Как итог у нас есть два возможных решения такой проблемы — обрезать файл или закрыть дескриптор.

P.S. Извиняюсь за картинки. Так и не понял, как здесь можно вставлять stdout без потери форматирования. Если кто-то в комментах подскажет - будет супер.

Всем привет! Я начинающий системный администратор, и у меня вопрос к знающим людям. Дали мне на время попользоваться коммутатор Zyxel GS1900-8, хотел только начать работу с ним, как столкнулся с тем, что при включении питания индикаторы всех портов загораются и так горят, хотя еще ни один кабель не подключен, при этом индикатор SYS не горит совсем. Ну и соответственно при попытке подключения кабеля ничего не меняется, а компьютер ничего не видит, так как сигнал не поступает. Пробовал нажимать ресет, не помогает. Коммутатор неисправен, или с этим можно что то сделать?

UPD: в комментах люди пишут, что может БП не подходить, хотя по цифрам совпадает