Как убрать приветствие в Centos

Обновлено: 21.11.2024

Мы настраиваем обратный прокси-сервер, защищающий доступ к приложению и защищающий сервер приложений от Интернета. При этом мы познакомимся с несколькими методами настройки и будем работать с ModRewrite впервые.

Зачем мы это делаем?

Требования

Ниже приведен рекомендуемый набор требований. На самом деле вам все это не нужно, но если вы будете старательно им следовать, я уверен, что все примеры будут работать 1:1. Если вы выберете более короткий путь, вероятно, потребуется некоторая настройка с путями и предопределенными псевдонимами.

Веб-сервер Apache, в идеале созданный с использованием файловой структуры, показанной в Уроке 1 (Сборка веб-сервера Apache).
Понимание минимальной конфигурации из Учебника 2 (Настройка минимального сервера Apache).
Веб-сервер Apache с поддержкой SSL/TLS, как показано в Уроке 4 (Настройка сервера SSL).
Веб-сервер Apache с расширенным журналом доступа, как показано в Уроке 5 (Расширение и анализ журнала доступа).
Веб-сервер Apache с ModSecurity, как показано в Уроке 6 (Внедрение ModSecurity).
Веб-сервер Apache с основным набором правил, как показано в Уроке 7 (включая основной набор правил)

Шаг 1. Подготовка серверной части

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

Шаг 2. Включение прокси-модуля

Для использования Apache в качестве прокси-сервера требуется несколько модулей. Мы скомпилировали их в первом уроке и теперь можем просто связать их.

Этот режим также возможен в Apache, хотя и по историческим причинам. Альтернативные программные пакеты, предлагающие эти функции, хорошо зарекомендовали себя, например. Кальмар. Этот случай актуален, поскольку ошибочная конфигурация может иметь фатальные последствия, особенно если прямой прокси-сервер принимает запросы от любого клиента и отправляет их дальше в Интернет в анонимной форме. Это называется открытым прокси. Это необходимо предотвратить, так как мы не хотим использовать Apache в этом режиме. Для этого требуется директива, которая в прошлом использовалась для ссылки на рискованное значение по умолчанию по умолчанию, но теперь правильно предопределена как off :

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

Шаг 3. Прокси-пасс

Это подводит нас к фактическим настройкам прокси: существует множество способов указать Apache пересылать запрос серверному приложению. Мы рассмотрим каждый вариант по очереди. Наиболее распространенный способ проксирования запросов основан на директиве ProxyPass. Он используется следующим образом:

Самая важная директива — ProxyPass. Он определяет путь /service1 и указывает, как он сопоставляется с серверной частью: с определенной выше службой, работающей на нашем собственном хосте, localhost, на порту 8000. Путь к серверу приложений снова /service1 . Мы проксируем симметрично, потому что путь к интерфейсу идентичен пути к серверу. Однако это сопоставление не является абсолютно обязательным. Технически было бы вполне возможно проксировать service1 на / , но это приводит к административным трудностям и недоразумениям, если путь в файле журнала приложения больше не сопоставляется с путем на обратном прокси-сервере, и запросы больше не могут быть легко сопоставлены.

Шаг 4. Прокси-раздел

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

Блок прокси похож на расположение и блок каталогов, с которыми мы уже познакомились в нашей конфигурации. Это так называемые контейнеры. Контейнеры указывают веб-серверу, как структурировать работу. Когда контейнер появляется в конфигурации, он готовит для него структуру обработки. В случае с mod_proxy доступ к серверной части также возможен без контейнера Proxy. Однако защита доступа не принимается во внимание, и другие директивы больше не имеют места, куда ее можно вставить. Без блока Proxy обработка сложных серверов остается немного бессистемной, и было бы неплохо настроить и эту часть. Используя директиву ProxySet, мы могли бы вмешаться еще больше и указать такие вещи, как поведение соединения. Min, max и smax могут использоваться для указания количества потоков, назначенных пулу прокси-соединений. Это может влиять на производительность от случая к случаю.На поведение поддержания активности прокси-соединения можно влиять, и для него можно определить множество различных тайм-аутов. Дополнительная информация доступна в документации проекта Apache.

Шаг 5. Определение исключений при проксировании и другие настройки

Используемая нами директива ProxyPass перенаправляет все запросы для /service1 на серверную часть. Однако на практике часто бывает так, что вы не хотите пересылать все подряд. Предположим, есть путь /service1/admin, который мы не хотим показывать в Интернете. Этого также можно избежать с помощью соответствующей настройки ProxyPass, где исключение инициируется с помощью восклицательного знака. Важно определить исключение перед настройкой фактической команды прокси:

Вы часто видите конфигурации, которые перенаправляют все пространство имен ниже / на серверную часть. Затем часто определяется ряд исключений из приведенного выше шаблона. Я думаю, что это неправильный подход, и я предпочитаю пересылать только то, что действительно обрабатывается. Преимущество очевидно: сканеры и автоматические атаки, ищущие следующую жертву из пула IP-адресов в Интернете, запрашивают множество несуществующих путей на нашем сервере. Теперь мы можем перенаправить их на серверную часть и можем перегрузить серверную часть или даже подвергнуть ее опасности. Или мы можем просто сбросить эти запросы на обратный прокси-сервер. Последнее явно предпочтительнее по соображениям безопасности.

Важная директива, которая может быть опционально частью прокси, касается времени ожидания. Мы определили собственное значение тайм-аута для нашего сервера. Этот тайм-аут также используется сервером для соединения с бэкендом. Но это не всегда разумно, потому что, хотя мы можем ожидать от клиента, что он быстро выполнит свой запрос и не будет тянуть время, в зависимости от бэкэнд-приложения, обработка ответа может занять некоторое время. Для короткого общего тайм-аута, который разумно иметь для клиента из соображений безопасности, обратный прокси слишком быстро прерывает доступ к серверной части. По этой причине существует директива ProxyTimeout, которая влияет только на подключение к серверной части. Кстати, измерение времени — это не общее время обработки на серверной части, а продолжительность времени между IP-пакетами: когда серверная часть отправляет часть ответа, часы сбрасываются.

Шаг 6. Модификация

В дополнение к директиве ProxyPass для включения функций обратного прокси-сервера можно использовать модуль Rewrite. По сравнению с ProxyPass обеспечивает более гибкую настройку. До сих пор мы не видели ModRewrite. Так как это очень важный модуль, мы должны хорошенько его рассмотреть.

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

Давайте посмотрим на такой запрос и возвращенное перенаправление:

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

Теперь вы можете спросить себя, почему мы открываем механизм перезаписи в контексте сервера и не работаем со всем на уровне VirtualHost. В примере, который я выбрал, вы видите, что это приведет к избыточности, потому что перенаправление с «/» на «index.html» должно происходить через порт 80, а также через зашифрованный порт 443. Это эмпирическое правило: это лучше всего для нам определять и наследовать все, что используется на всех виртуальных хостах в контексте сервера. На этом уровне мы также имеем дело с отдельными правилами для одного виртуального хоста. Обычно для перенаправления всех запросов с порта 80 на порт 443, где включено шифрование, используется следующее правило:

Теперь схема, которую мы хотим, ясна. Но слева от него появляется новый предмет. Мы не подавляем путь так быстро, как указано выше. Вместо этого мы помещаем его в круглые скобки и используем $1, чтобы снова ссылаться на содержимое круглых скобок в перенаправлении. Это означает, что мы перенаправляем запрос на порт 80, используя тот же URL-адрес на порту 443.

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

Шаг 7: ModRewrite [прокси]

Давайте воспользуемся ModRewrite для настройки обратного прокси-сервера. Делаем это следующим образом:

Это достаточно для настройки с использованием правила перезаписи. В этом примере нет реального преимущества перед синтаксисом ProxyPass. Однако ссылки на части путей с использованием $1 , $2 и т. д. обеспечивают некоторую гибкость. Но если мы все равно работаем с правилами перезаписи, то путем проксирования правил перезаписи мы гарантируем, что RewriteRule и ProxyPass не вступят в конфликт, затрагивая один и тот же запрос и влияя друг на друга.

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

Шаг 8. Балансировщик [прокси]

Сначала нам нужно загрузить модуль балансировки нагрузки Apache:

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

Вот список всех четырех доступных алгоритмов:

mod_lbmethod_byrequests (подсчитывает запросы)
mod_lbmethod_bytraffic (суммарный размер запросов и ответов)
mod_lbmethod_bybusyness (балансировка нагрузки на основе активных потоков в соединении, установленном с серверной частью. Серверная часть с наименьшим количеством потоков получает следующий запрос)
mod_lbmethod_heartbeat (серверная часть может даже связываться через пульсацию в сети и использовать ее для информирования обратного прокси-сервера о том, есть ли у него свободная емкость).

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

Наконец, нам все еще нужен модуль, который поможет нам управлять общими сегментами памяти. Эти функции требуются модулем балансировки прокси и предоставляются mod_slotmem_shm.so .

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

Помимо заголовка keep-alive, интерес представляет также обработчик запросов. Таким образом, запрос был обработан обработчиком прокси-сервера. Мы также видим записи для маршрута, в частности значения, определенные как backend-port-8000 и backend-port-8001. Это позволяет определить из журнала доступа сервера точный маршрут запроса.

В следующем руководстве мы увидим, что балансировщик прокси можно использовать и в других ситуациях. Однако на данный момент мы будем довольны тем, что происходит, и теперь обратимся к RewriteMaps. RewriteMap — это вспомогательная структура, которая снова увеличивает возможности ModRewrite. В сочетании с прокси-сервером гибкость значительно возрастает.

Шаг 9. Перезапись карты [прокси]

Карты RewriteMaps бывают разных вариантов. Они работают, присваивая значение ключевому параметру при каждом запросе. Хеш-таблица — простой пример. Но тогда также можно настроить внешние сценарии как программируемый RewriteMap. Возможны следующие типы карт:

txt : здесь ищется пара ключ-значение в текстовом файле.
rnd: здесь можно указать несколько значений для каждого ключа. Затем они выбираются случайным образом.
dbm : этот вариант работает так же, как вариант txt, но дает большое преимущество в скорости, поскольку используется двоичная хэш-таблица.
int : эта аббревиатура означает внутреннюю функцию и относится к функции из следующего списка: toupper , tolower , escape и unescape .
prg : в этом варианте вызывается внешний скрипт. Сценарий запускается вместе с сервером, и каждый раз при доступе к RewriteMap получает новые данные через STDIN.
dbd и fastdbd : значение ответа ищется в запросе к базе данных.

Из этого списка видно, что карты RewriteMaps чрезвычайно гибки и могут использоваться в различных ситуациях. Определение бэкенда для проксирования — это только одно из многих возможных применений. В нашем примере мы хотим, чтобы запрос от конкретного клиента всегда направлялся к одному и тому же бэкенду. Это можно сделать несколькими способами, в частности, путем установки файла cookie. Но мы не хотим вмешиваться в запросы. Мы могли бы разделить по диапазонам сети. Но как предотвратить попадание большого количества клиентов из определенного сетевого диапазона в один и тот же сервер? Должна быть какая-то раздача. Для этого мы комбинируем ModSecurity с использованием ModRewrite и RewriteMap. Давайте рассмотрим это шаг за шагом.

Сначала мы вычисляем хеш-значение на основе IP-адреса клиента. Это означает, что мы преобразуем IP-адрес в, казалось бы, случайную шестнадцатеричную строку, используя ModSecurity:

Мы использовали hexEncode для преобразования двоичного хеш-значения, сгенерированного с помощью sha1, в читаемые символы. Затем мы применяем регулярное выражение к этому значению. «^(.)» означает, что мы хотим найти совпадение по первому символу. Из флагов ModSecurity, которые следуют за захватом, представляет интерес. Это указывает на то, что мы хотим зафиксировать значение в круглых скобках в предыдущем условии регулярного выражения. Затем мы помещаем его в переменную среды IPHashChar.

Если есть какая-то неуверенность в том, будет ли это действительно работать, то содержимое переменной IPHashChar можно распечатать и проверить с помощью %e в журнале доступа к серверу. Это подводит нас к RewriteMap и самому запросу:

Мы вводим карту с помощью команды RewriteMap. Присваиваем ему имя, определяем его тип и путь к файлу. RewriteMap вызывается в RewriteRule. Прежде чем мы действительно получим доступ к карте, мы включаем условие перезаписи. Это делается с помощью директивы RewriteCond. Там мы ссылаемся на переменную среды IPHashChar и определяем первый байт переменной. Мы знаем, что в вариант включен только один байт, но это не помешает нашим планам. На следующей строке типичное начало директивы Proxy. Но вместо того, чтобы теперь указывать серверную часть, мы ссылаемся на RewriteMap по ранее назначенному имени. После двоеточия идет параметр запроса. Интересно, что мы используем %1 для связи с условиями перезаписи, заключенными в скобки. На переменную RewriteRule это не влияет, и на нее по-прежнему ссылаются через $1. После %1 идет значение по умолчанию, разделенное вертикальной чертой. Если что-то пойдет не так при доступе к карте, связь с локальным хостом будет осуществляться через порт 8000.

Все, что нам нужно сейчас, это RewriteMap. В примере кода мы указали текстовый файл. Лучшая производительность обеспечивается хэш-файлом, но в настоящее время это не главное. Вот файл карты /apache/conf/hashchar2backend.txt:

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

Шаг 10. Передача информации в серверные системы

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

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

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

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

Шаг 11 (полезный): настройка полного обратного прокси-сервера

Это небольшое дополнение подводит нас к концу этого руководства, а также к концу основного блока различных руководств. В нескольких руководствах мы увидели, как настроить веб-сервер Apache для лаборатории, от его компиляции до базовой конфигурации и настройки ModSecurity для обратных прокси, получив глубокое представление о том, как работает сервер и его наиболее важные модули.< /p>

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

Информационный бюллетень

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

Ссылки

Лицензия/Копирование/Дальнейшее использование

Эта работа находится под лицензией Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

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

Как изменить индексную страницу по умолчанию на веб-сервере Apache

Вот шаги, чтобы изменить индексную страницу по умолчанию на веб-сервере Apache.Вы можете изменить индексную страницу по умолчанию через файл конфигурации Apache Server или с помощью файла .htaccess. Ниже мы рассмотрим оба подхода.

Изменить индексную страницу по умолчанию с помощью конфигурации Apache

Файл конфигурации Apache находится в одном из следующих мест в зависимости от вашей установки:

Откройте терминал и выполните следующую команду, чтобы открыть файл конфигурации Apache

Вы увидите следующие строки кода.

Замените index.html index.php на веб-страницу по вашему выбору (например, home.html).

Убедитесь, что вы разместили этот файл home.html в папке /var/www/html/. Если вы поместили его в другую папку (например, /var/www/html/product/), измените указанный выше путь соответствующим образом (например, /product/home.html). .

Вы также можете добавить несколько индексных страниц в Apache, как показано ниже

Перезапустите веб-сервер Apache, чтобы изменения вступили в силу.

Изменить индексную страницу по умолчанию с помощью .htaccess

Вы также можете изменить индексную страницу по умолчанию для Apache с помощью .htaccess. Прежде чем продолжить, включите mod_rewrite (.htaccess) на веб-сервере Apache.

Откройте файл .htaccess, обычно расположенный в /var/www/html/.htaccess

Добавьте следующую строку в файл .htaccess, чтобы установить индексную страницу на home.html.

Перезапустите веб-сервер Apache, чтобы изменения вступили в силу.

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

Об Убике

Ubiq – это мощная панель мониторинга и отчетности для малого и среднего бизнеса. Создавайте информационные панели, диаграммы и отчеты для своего бизнеса за считанные минуты. Быстро получайте информацию из данных. Попробуйте бесплатно сегодня!

Пришло время повеселиться в cgroups! В этом посте мы рассмотрим контрольные группы (cgroups) v2, которые поддерживаются в Red Hat Enterprise Linux 8.

Возможно, мы выпустили новую версию RHEL. Иногда такое случается.

7 мая 2019 г. Red Hat официально выпустила Red Hat Enterprise Linux 8. Ура! По умолчанию RHEL 8 не сильно отличается от пользовательского интерфейса RHEL 7, по крайней мере, на первый взгляд. Например, мы все еще используем такие вещи, как systemd, GNU Bash, Network Manager и yum. (Хотя теперь у yum совершенно новый блестящий движок под капотом.)

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

Пользовательские сеансы, представляющие собой особый тип временного фрагмента, известного как "временный фрагмент", теперь снова учитывают вставные файлы. Это поведение перестало работать в RHEL 7.4 из-за вышестоящих изменений в том, как система обрабатывает временные срезы. Вы также можете изменить их настройки на лету с помощью команд systemctl set-property. Место для вставки файлов изменилось, когда используется свойство systemctl set-property. Вставки теперь хранятся в /etc/systemd/system.control .

RHEL 8 поддерживает cgroups v2. Это большой вопрос, и сегодня я в основном сосредоточусь на нем.

Группы управления v2 – общая картина

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

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

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

Давайте посмотрим, чем отличаются две версии. Я покажу две разные схемы: контроллеры в желтых блоках, а каталоги cgroup на сером фоне.

На диаграмме ниже показано, что в случае cgroups v1 каждый контроллер может иметь под собой одну или несколько cgroup, а также вложенные группы внутри. Процесс может находиться в любой из этих контрольных групп или во всех (ну, по одной на контроллер), и пользователь должен убедиться, что комбинация контрольных групп является разумной.

В случае cgroups v2 существует единая иерархия cgroups. Каждая cgroup использует управляющий файл cgroup.subtree_control, чтобы определить, какие контроллеры активны для дочерних элементов в этой конкретной cgroup. Как сказано в нашей онлайн-документации: «По сути, в CGroups v1 контрольные группы связаны с контроллерами, тогда как в CGroups v2 контроллеры связаны с контрольными группами».

На следующем изображении показана структура каталогов созданных контрольных групп.Контроллеры, активные для этих групп, размещены в ряд на графике. Так, например, C1 и C2 имеют активный контроллер ЦП. C3 и C4 также имеют контроллер ЦП от своего родителя и активный контроллер памяти.

На портале клиентов есть документ, в котором отслеживается текущее состояние cgroups V2. Если вам интересно, как cgroups будут меняться в течение жизненного цикла RHEL, это хорошая статья. В этом же документе дается руководство по активации cgroups v2. По сути, единственный полностью поддерживаемый метод — добавить systemd.unified_cgroup_hierarchy=1 в строку загрузки ядра в grub.conf .

Деятельность и жестокость

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

Я вошел в roland, виртуальную машину RHEL 8. В настоящее время он использует cgroups v1, так что давайте посмотрим, как это выглядит.

Ничего странного. Теперь мы собираемся изменить строку загрузки ядра в /etc/default/grub и пересобрать grub.conf .

Как видите, я закомментировал исходный GRUB_CMDLINE_LINUX и добавил версию, включающую systemd.unified_cgroup_hierarchy=1 . Затем я пересобрал файл grub.conf с помощью grub2-mkconfig . Помните, дети, не редактируйте grub.conf вручную в RHEL 7 или RHEL 8.

Давайте перезагрузим Роланда и посмотрим, как выглядит его файловая система постфактум.

Это немного другой вид. Мы больше не видим контроллеры — фактически теперь мы видим активные слайсы по умолчанию на верхнем уровне ( system.slice и user.slice )

Глядя на пользовательский фрагмент, мы видим подкаталог с именем user-0.slice . Если вы помните из предыдущих блогов, каждый авторизованный пользователь получает часть под пользовательской частью верхнего уровня. Они идентифицируются не по именам, а по UID. Таким образом, user-0.slice — всеми любимый суперпользователь root.

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

Для пользователя user-1000.slice создан новый подкаталог, который соответствует моему текущему UID.

Пока все это не является необоснованным или нарушает какие-либо вещи, которые мы уже узнали.

Теперь, поскольку у меня есть история использования roland для работы с очень интенсивным использованием процессора, владелец системы постановил, что мне будет предоставлена довольно жесткая квота. Если мы посмотрим, то увидим, что для этого пользовательского фрагмента существует вставной файл, созданный этим подлым системным администратором.

Это ограничивает UID 1000 до 10 % от одного ЦП. Посмотрим, активен ли он. Я запускаю foo.exe , который потребляет столько процессорного времени, сколько может получить, а затем проверяет top :

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

Наш администратор изменяет квоту на 50%

Давайте посмотрим на внутренние изменения, происходящие в виртуальной файловой системе:

На этом снимке мы видим, что в user.slice значение cpu.max по умолчанию (которое на самом деле устанавливает CPUQuota) составляет 100 000 тиков без ограничений. После установки квоты дочерний слайс user-1000.slice имеет максимальную нагрузку процессора 50 000 тиков на 100 000 тиков, другими словами, 50 % времени ЦП – это максимально допустимое использование.

Наконец, давайте поговорим об определении cgroup, в которой может находиться процесс, а также о новом «правиле» для версии 2 и подключении процессов.

На этой шапке экрана есть что распаковать, так что давайте потихоньку.

Как видите, под user-1000.slice на самом деле есть два элемента. Сейчас мы проигнорируем user@1000.service и посмотрим на session-3.scope .

Область находится внутри среза и наследует настройки — это очень временная часть иерархии. С cgroups v1 процесс можно было присоединить практически к любой части иерархии. В cgroups v2 процесс ДОЛЖЕН жить на «листе» — другими словами, в части иерархии, у которой нет потомков. В случае с нашим текущим пользователем это будет session-3.scope. PID для процесса в cgroup находится в cgroup.procs — как мы видим, в области видимости работает 5 PID, когда я запускаю команду cat (cat — один из них)

Чтобы поместить процесс в контрольную группу вручную, вы можете вывести PID в соответствующий файл cgroup.procs. Если вы попытаетесь сделать это для члена иерархии, который не является листом, это не удастся. Давайте еще раз посмотрим на нашу иерархию V2.

Разрешено переместить процесс в C1, C3 или C4. Попытка поместить процесс в C2 потерпит неудачу, так как у него есть дочерние контрольные группы.

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

Должен ли я использовать cgroups v2?

Отличный вопрос. Рад, что вы спросили об этом.

RHEL 8 поставляется с cgroups v1 по умолчанию. За этим есть веская причина. Вероятно, самым важным является то, что для следующих пакетов, начиная с RHEL 8.0, требуется версия 1:

Поэтому, если в вашей системе RHEL 8 прямо сейчас размещаются контейнеры или виртуальные машины KVM, рекомендуется придерживаться cgroups v1. Теперь в настоящее время открыты Bugzilla для полной поддержки всех этих вариантов использования в RHEL 8, но их не удалось завершить к дате запуска. Кроме того, намерение состоит в том, чтобы версия 1 оставалась стандартной по умолчанию. Версия 1 по-прежнему будет доступна как часть RHEL 8.

Если в ваших системах выполняются рабочие нагрузки, не требующие этих функций, cgroups v2 может предложить более простой способ управления вашими ресурсами. Если вы разрабатываете сервисы и приложения, это отличная возможность увидеть, как они взаимодействуют с v2. Я считаю, что в конечном итоге мы увидим все варианты использования, поддерживаемые в версии 2 в RHEL 8, поэтому, возможно, стоит потратить время на обучение сейчас, чтобы вы могли сразу же взяться за дело. Вы всегда можете рассматривать cgroups v2 как предварительную техническую версию, если хотите, даже несмотря на то, что эта функция фактически готова к эксплуатации и полностью поддерживается.

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

Серия "Мировое господство с Cgroups":

Как всегда, спасибо, что провели с нами немного времени и наслаждались вашим стремлением к мировому господству!

Примечание: информация о вставных файлах была изменена по состоянию на 24 апреля 2020 г.

Повреждение initramfs может происходить разными способами, например, после исправления ОС CentOS 7 Linux или установки ошибочного драйвера устройства на сервер, который вы обнаружили, что сервер CentOS 7 Linux перестал загружаться. Вы также можете столкнуться с ошибкой паники ядра ниже, потому что initramfs сервера были повреждены.

Экран CentOS 7 Linux Kernel Panic

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

В этом руководстве я покажу вам, как восстановить загрузочный образ CentOS 7 Linux initramfs в таком случае, когда на сервере нет старого или предыдущего ядра для загрузки.

Что такое initramfs и насколько он важен для системы Linux в процессе загрузки?

Во время загрузки Linux initramfs загружается в память и монтирует корневую файловую систему, initramfs содержит модули ядра и начальные сценарии, необходимые для загрузки системы Linux до следующего этапа загрузки. Файлы initramfs остаются в точке монтирования /boot или каталоге в формате файла образа, связанном с версией установленного ядра: initramfs-.img. Каждый раз, когда в системе устанавливается новое ядро, создаются новые initramfs. Утилита, которую можно использовать для управления и восстановления initramfs в случае повреждения образа initramfs.

Каталог загрузки CentOS 7 Linux

Вы можете увидеть содержимое текущих файлов initramfs в системе CentOS 7 Linux с помощью примера команды lsinitrd ниже:

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

Восстановление или пересборка поврежденного загрузочного образа initramfs

Мы будем использовать утилиту dracut, как я упоминал выше, для восстановления поврежденных файлов initramfs, чтобы снова сделать систему CentOS7 Linux загружаемой.

Перезагрузите систему и загрузитесь в аварийный образ ядра.

Войдите в систему с учетными данными пользователя root или sudo.
На снимке экрана ниже видно, что существующий файл initramfs не имеет видимого размера, что является признаком его повреждения.

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

После выполнения команды dracut на снимке экрана ниже видно, что initramfs успешно перестроен с видимым размером файла.

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

Читайте также: