Мне регулярно пишут и спрашивают на тему того, каким дистрибутивом linux для серверов лучше пользоваться и что ставлю я сам. В свете истории с Centos, такие вопросы стали появляться почти каждый день. Отвечаю разом всем, кто ко мне с таким вопросом обращался. Многих я проигнорировал, потому что нет возможности отвечать всем, кто мне пишет.
Сам я в настоящее время везде устанавливаю Centos 8. К концу 2021 года, я думаю, станет более ли менее ясно, на какой форк RHEL имеет смысл переключиться. Процесс этот простой и быстрый. Все текущие форки предоставляют такую возможность. Надо будет просто подключить их репу и поставить какой-нибудь пакет, либо запустить bash скрипт. И все, вы превратите свой Centos 8 в Oracle Linix 8 или что-то другое. Я не вижу в этом проблемы, поэтому не суечусь.
Мне видится неплохим вариантом использовать 16 бесплатных лицензий, которые предоставляет RedHat по Developer подписке. Если бы я был админом в небольшой компании, я бы наверное поставил RHEL и вообще не заморачивался. Но так как у меня много всевозможных проектов и не везде получится использовать RHEL или 16-ти лицензий будет недостаточно, я его скорее всего не буду ставить, чтобы сохранить единообразие дистрибутивов во всех проектах, что я администрирую. Так что я буду ждать и выбирать какой-то форк.
Много вопросов, почему не Ubuntu / Debian. Убунта мне не нравится, потому что там постоянно идут изменения. То одно поменяют, то другое, то третье. Сейчас опять выкатывают новый установщик. Мне не нравится эта вечная суета с обновлениями и переучиванием, когда я не получаю практической пользы от предложенных изменений. Мне, к примеру, нравится, что в Centos с 5-й версии плюс, минус один и тот же установщик. Зачем его менять?
В Debian изменений меньше, но мне не нравится жизненный цикл релиза в 5 лет. 5 лет вроде бы много, но это если ты ставишь систему сразу после ее релиза. А если прошло почти 2 года, нового релиза еще нет. Ты ставишь существующий и получаешь время поддержки чуть более трех лет. Это мало. Да, можно обновлять релизы, но лично я в проде этого никогда не делаю. Я считаю, что обновление релиза потенциально небезопасная процедура, так что подходить к ней надо со всевозможными подстраховками, тестированием и т.д. То есть тратить на это время.
Таким образом, лично мне оптимальна система типа Centos с жизненным циклом релиза в 10 лет. У меня так получается, что я всегда работаю в долгую. Есть сервера, которыми я управляю уже более 5-ти лет. Занимался обновлением Centos 5, 6. Сейчас еще есть сервера на 6-й версии, которые я ставил. Им предстоит обновление. Мне чем дольше актуален релиз, тем лучше.
А вы как на все это смотрите? На чем остановили свой выбор в качестве linux сервера для прода?
#centos #debian #ubuntu
Сам я в настоящее время везде устанавливаю Centos 8. К концу 2021 года, я думаю, станет более ли менее ясно, на какой форк RHEL имеет смысл переключиться. Процесс этот простой и быстрый. Все текущие форки предоставляют такую возможность. Надо будет просто подключить их репу и поставить какой-нибудь пакет, либо запустить bash скрипт. И все, вы превратите свой Centos 8 в Oracle Linix 8 или что-то другое. Я не вижу в этом проблемы, поэтому не суечусь.
Мне видится неплохим вариантом использовать 16 бесплатных лицензий, которые предоставляет RedHat по Developer подписке. Если бы я был админом в небольшой компании, я бы наверное поставил RHEL и вообще не заморачивался. Но так как у меня много всевозможных проектов и не везде получится использовать RHEL или 16-ти лицензий будет недостаточно, я его скорее всего не буду ставить, чтобы сохранить единообразие дистрибутивов во всех проектах, что я администрирую. Так что я буду ждать и выбирать какой-то форк.
Много вопросов, почему не Ubuntu / Debian. Убунта мне не нравится, потому что там постоянно идут изменения. То одно поменяют, то другое, то третье. Сейчас опять выкатывают новый установщик. Мне не нравится эта вечная суета с обновлениями и переучиванием, когда я не получаю практической пользы от предложенных изменений. Мне, к примеру, нравится, что в Centos с 5-й версии плюс, минус один и тот же установщик. Зачем его менять?
В Debian изменений меньше, но мне не нравится жизненный цикл релиза в 5 лет. 5 лет вроде бы много, но это если ты ставишь систему сразу после ее релиза. А если прошло почти 2 года, нового релиза еще нет. Ты ставишь существующий и получаешь время поддержки чуть более трех лет. Это мало. Да, можно обновлять релизы, но лично я в проде этого никогда не делаю. Я считаю, что обновление релиза потенциально небезопасная процедура, так что подходить к ней надо со всевозможными подстраховками, тестированием и т.д. То есть тратить на это время.
Таким образом, лично мне оптимальна система типа Centos с жизненным циклом релиза в 10 лет. У меня так получается, что я всегда работаю в долгую. Есть сервера, которыми я управляю уже более 5-ти лет. Занимался обновлением Centos 5, 6. Сейчас еще есть сервера на 6-й версии, которые я ставил. Им предстоит обновление. Мне чем дольше актуален релиз, тем лучше.
А вы как на все это смотрите? На чем остановили свой выбор в качестве linux сервера для прода?
#centos #debian #ubuntu
Знатную уязвимость подвезли в Linux под номером CVE-2022-0185. Обычно не публикую крупные новости, которые и так из всех источников идут, но тут решил сделать исключение из-за эпичности дыры. Наверняка полно людей, кто не знает о ней. Я сам только вчера вечером прочитал.
Имея права пользователя в системе, можно получить root. Демонстрация работы есть на Github. Подобная уязвимость работает во всех Ubuntu из-за того, что там по дефолту включены user namespaces, чего нет, к примеру, в Debian и RHEL, если не используются контейнеры. Вот тут то ориентированность на простоту и удобство Ubuntu сыграла злую шутку. Чтобы лишний раз не дёргать настройку, её включили по дефолту.
Но вообще, это уязвимость ядра Linux 5.1 и выше, так что все другие дистры с этим ядром тоже ей подвержены и обязательно нужно обновляться, если на хосте используются контейнеры. Если у вас Centos 7 или Ubuntu 18, можно не суетиться. Там более старые ядра.
Если обновление по какой-то причине невозможно, то user_namespaces Redhat советует отключить вот так:
А Ubuntu так:
Хороший повод лишний раз поразмыслить над удобством контейнеров. В виртуальных машинах получить такую дырищу значительно труднее. Я вообще не припомню, чтобы были CVE с побегом из VM на хост. А в контейнерах уже не первый раз.
Примечательно, что код, содержащий эту уязвимость, добавлен около трех лет назад. Кто-то всё это время мог эксплуатировать уязвимость. А сколько их ещё таких там есть?
https://ubuntu.com/security/CVE-2022-0185
https://access.redhat.com/security/cve/CVE-2022-0185
https://bugzilla.redhat.com/show_bug.cgi?id=2040358
#security #ubuntu #docker #devops
Имея права пользователя в системе, можно получить root. Демонстрация работы есть на Github. Подобная уязвимость работает во всех Ubuntu из-за того, что там по дефолту включены user namespaces, чего нет, к примеру, в Debian и RHEL, если не используются контейнеры. Вот тут то ориентированность на простоту и удобство Ubuntu сыграла злую шутку. Чтобы лишний раз не дёргать настройку, её включили по дефолту.
Но вообще, это уязвимость ядра Linux 5.1 и выше, так что все другие дистры с этим ядром тоже ей подвержены и обязательно нужно обновляться, если на хосте используются контейнеры. Если у вас Centos 7 или Ubuntu 18, можно не суетиться. Там более старые ядра.
Если обновление по какой-то причине невозможно, то user_namespaces Redhat советует отключить вот так:
# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf# sysctl -p /etc/sysctl.d/userns.confА Ubuntu так:
# sysctl -w kernel.unprivileged_userns_clone = 0Хороший повод лишний раз поразмыслить над удобством контейнеров. В виртуальных машинах получить такую дырищу значительно труднее. Я вообще не припомню, чтобы были CVE с побегом из VM на хост. А в контейнерах уже не первый раз.
Примечательно, что код, содержащий эту уязвимость, добавлен около трех лет назад. Кто-то всё это время мог эксплуатировать уязвимость. А сколько их ещё таких там есть?
https://ubuntu.com/security/CVE-2022-0185
https://access.redhat.com/security/cve/CVE-2022-0185
https://bugzilla.redhat.com/show_bug.cgi?id=2040358
#security #ubuntu #docker #devops
Иногда возникают ситуации, когда у сервера по той или иной причине нет доступа в интернет. У меня лично теперь есть такие сервера. А вам нужно как-то обновлять и устанавливать пакеты и желательно не вручную. Для этого можно поднять свой репозиторий и вручную управлять им, обновляя все остальные машины через него. Это сложный путь и не всегда оправданный, если вам нужно обновлять одну машину, да и то не регулярно.
Для решения подобной проблему есть удобный инструмент - apt-offline (https://github.com/rickysarraf/apt-offline). Как видно из названия он актуален для DEB дистрибутивов. Я его использовал для Debian. Качаете архив с последним релизом из репозитория, копируете и распаковываете на сервере без интернета. В нём будет бинарник apt-offline, с ним и будем работать.
Для начала обновим репозитории на сервере:
Тут же в директории будет создан файл apt-offline.sig. Теперь можно всю папку с apt-offline и этим файлом перенести на сервер с интернетом и там запустить:
Информация с содержимым репозиториев будет сохранена в файл bundle.zip. Возвращаемся на сервер без инета и там запускаем обновление реп:
Теперь обновим все пакеты целевого сервера:
Идём на компьютер с интернетом и там качаем пакеты:
Будут скачаны все обновления пакетов и зависимости. Опять берём всю директорию и копируем на сервер без инета. Там запускаем:
Для установки только одного пакета делаем следующее:
Копируем папку на комп с инетом и там выполняем:
Возращаем на комп без инета и запускаем установку пакета:
У вас есть в хозяйстве сервера без интернета? У меня это некоторые сервера с бэкапами, правда там я сам вручную включаю инет когда надо, а потом отключаю. А вот полностью без инета приходилось работать у некоторых заказчиков. Таскал туда руками пакеты, пока не узнал про apt-offline. На днях про него вспомнил и написал заметку.
#debian #ubuntu
Для решения подобной проблему есть удобный инструмент - apt-offline (https://github.com/rickysarraf/apt-offline). Как видно из названия он актуален для DEB дистрибутивов. Я его использовал для Debian. Качаете архив с последним релизом из репозитория, копируете и распаковываете на сервере без интернета. В нём будет бинарник apt-offline, с ним и будем работать.
Для начала обновим репозитории на сервере:
# ./apt-offline set --update apt-offline.sigТут же в директории будет создан файл apt-offline.sig. Теперь можно всю папку с apt-offline и этим файлом перенести на сервер с интернетом и там запустить:
# ./apt-offline get --bundle bundle.zip apt-offline.sigИнформация с содержимым репозиториев будет сохранена в файл bundle.zip. Возвращаемся на сервер без инета и там запускаем обновление реп:
# ./apt-offline install bundle.zipТеперь обновим все пакеты целевого сервера:
# ./apt-offline set --update --upgrade apt-offline.sigИдём на компьютер с интернетом и там качаем пакеты:
# ./apt-offline get --bundle bundle.zip apt-offline.sigБудут скачаны все обновления пакетов и зависимости. Опять берём всю директорию и копируем на сервер без инета. Там запускаем:
# ./apt-offline install bundle.zip# apt upgradeДля установки только одного пакета делаем следующее:
# ./apt-offline set --install-packages PACKAGENAME --update apt-offline.sigКопируем папку на комп с инетом и там выполняем:
# ./apt-offline get --bundle bundle.zip apt-offline.sigВозращаем на комп без инета и запускаем установку пакета:
# ./apt-offline install bundle.zip# apt install PACKAGENAMEУ вас есть в хозяйстве сервера без интернета? У меня это некоторые сервера с бэкапами, правда там я сам вручную включаю инет когда надо, а потом отключаю. А вот полностью без инета приходилось работать у некоторых заказчиков. Таскал туда руками пакеты, пока не узнал про apt-offline. На днях про него вспомнил и написал заметку.
#debian #ubuntu
GitHub
GitHub - rickysarraf/apt-offline: Offline APT Package Manager
Offline APT Package Manager. Contribute to rickysarraf/apt-offline development by creating an account on GitHub.
Никогда не понимал, почему вывод информации об устанавливаемых пакетах в apt-get, а потом и в apt такой неудобный. Вам просто вываливают лапшу перед глазами, где трудно что-то разобрать, например найти отдельный пакет. И ладно бы трудно было придумать что-то получше, но оно уже есть. Берём yum/dnf, там всё красиво и удобно. Почему нельзя сделать так же? Достаточно добавить форматирование.
Кажется, что это мелочь, но когда я пользовался Centos, меня прям отвращало от Debian и Ubuntu именно это поведение apt. Я не понимал, почему не сделать удобно, как в других дистрибутивах. Не понимаю я этого и сейчас. Когда впервые услышал про apt, как замену apt-get, думал, там это будет решено. Но нет.
Если хотите в Debian или Ubuntu получить нормальный вывод информации о пакетах при работе с пакетным менеджером, можете поставить Nala. Она не делает ничего особенного - просто приводит вывод apt в человекочитаемый вид. Ну и бонусом может параллельно скачивать пакеты в несколько потоков.
Поставить Nala можно либо из собранного пакета, либо из репозитория Testing/Sid самого Debian. Его нужно будет отдельно добавить в систему. Лучше этого не делать, чтобы случайно не обновиться с тестовых реп. Это необратимый процесс. Либо сразу после установки отключить его.
Я так понимаю, раз Nala уже в Testing/Sid, то есть шанс, что её перенесут в основной стабильный репозиторий. Было бы неплохо.
Исходники - https://gitlab.com/volian/nala
#debian #ubuntu
Кажется, что это мелочь, но когда я пользовался Centos, меня прям отвращало от Debian и Ubuntu именно это поведение apt. Я не понимал, почему не сделать удобно, как в других дистрибутивах. Не понимаю я этого и сейчас. Когда впервые услышал про apt, как замену apt-get, думал, там это будет решено. Но нет.
Если хотите в Debian или Ubuntu получить нормальный вывод информации о пакетах при работе с пакетным менеджером, можете поставить Nala. Она не делает ничего особенного - просто приводит вывод apt в человекочитаемый вид. Ну и бонусом может параллельно скачивать пакеты в несколько потоков.
Поставить Nala можно либо из собранного пакета, либо из репозитория Testing/Sid самого Debian. Его нужно будет отдельно добавить в систему. Лучше этого не делать, чтобы случайно не обновиться с тестовых реп. Это необратимый процесс. Либо сразу после установки отключить его.
Я так понимаю, раз Nala уже в Testing/Sid, то есть шанс, что её перенесут в основной стабильный репозиторий. Было бы неплохо.
Исходники - https://gitlab.com/volian/nala
#debian #ubuntu
⇨ Truenas Scale Electric Eel. Как же долго я тебя ждала
Вышло крупное обновление Trunas Scale - одно из лучших open source решений для NAS. Оказывается, в нём под капотом был Kebernetes 😱 В обновлении его заменили на Docker Compose. Содержательное видео по этому продукту.
⇨ OpenProject - Система для организации проектов. Обзор функций. Установка пакетов и docker
Обзор OpenProject - системы управления проектами с открытым исходным кодом. Популярная и функциональная система. Раньше про неё не слышал. Думаю, разверну и сделаю отдельную заметку.
⇨ Установка Speedtest Tracker на Synology
Обзор Speedtest Tracker для регулярной проверки и хранения результатов замеров скорости интернета. Не раз получал просьбы посоветовать что-то для регулярных замеров, чтобы был график и можно было отслеживать свой канал. Вот вариант решения задачи.
⇨ xPipe is a fantastic, amazing remote connection manager!
Обзор xPipe - менеджера для удалённых подключений. Я писал про него. Пользовался им некоторое время, но в итоге бросил. Докучали некоторые баги и его тормознутость. По виду и возможностям всё нравится, но на практике не зашло. Попробуйте, может вам понравится. Из особенностей - для подключений по SSH использует Windows Terminal. Лично мне это особенно нравилось.
⇨ What’s the better Git? // GitLab vs Gitea
Краткое сравнение GitLab и Gitea. Так то они сильно различаются. Не знаю, что сподвигло автора сравнить их в лоб. Наверное, тема популярная.
⇨ Self-host your own Git platform! // Gitea Tutorial
Вдогонку от этого же автора ролик про саму Gitea.
⇨ GitLab - Установка приватного GitLab Сервера с Ручной и Авто настройкой SSL + PASSWORD
Подробный урок по установке Gitlab. Рассмотрены и системные требования, и разные редакции и т.д. База для тех, кто не особо знаком с продуктом.
⇨ GitLab CI/CD - Полный DevOps Pipeline с НУЛЯ, Создание Docker Image и деплой в AWS ECS Fargate
Практический урок по созданию пайплайна в Gitlab. Он привязан к сервисам AWS. Пол урока создание там сущностей и раздача прав. Тем не менее показано всё наглядно для общего понимания, как это в принципе работает: разные ветки в git, ветвление деплоя в зависимости от ветки, переменные и т.д.
⇨ 7 Правил безопасности сервера
Автор рассмотрел некоторый набор правил для повышения безопасности сервера. Информация для новичков, набор тривиальный: не ходим под root, не используем пароль, прячем SSH порт и т.д.
⇨ PostgreSQL Clustering the Hard Way...
Тяжёлое для восприятия техническое видео на час по построению кластера на базе PostgreSQL. Смотреть имеет смысл, если вам актуальна эта тема. Кластер на базе Patroni.
⇨ Установка ONLYOFFICE в докер и связываем его с Nextcloud
Небольшая инструкция по настройке этой связки. Меня не раз спрашивали, как это настроить. Последний раз буквально неделю назад кто-то то ли в личку, то ли куда-то в комментарии писал.
⇨ SafeLine: A Feature-Rich WAF with a Catch (or Two)
Обзор open source self-hosted WAF. Не слышал про него ранее. Думаю, что попробую и напишу отдельную заметку.
⇨ Reubah: Optimize Your Images & Files Without Compromising Your Privacy
Функциональный open source продукт Rebuah для одиночной или пакетной обработки изображений. В целом ничего особенно, но выглядит аккуратно и удобно. Можно сразу перемотать на демонстрацию. Мне понравилось. В список программ для собственного применения записал.
⇨ The Perfect Home Server 2024 – 56TB, ECC, IPMI, Quiet & (kind of) Compact
Интересное описание сборки домашнего сервера с минимальным шумом с IPMI и ECC. Понравилась материнка из видео - gigabyte mc12-le0. К сожалению, не нашёл, где её у нас купить можно. На aliexpress тоже нету. У автора ролики очень хорошего качества. Огромное количество просмотров для такой узкой темы это подтверждают.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Truenas Scale Electric Eel. Как же долго я тебя ждала
#nas, #opnsense, #truenas, #proxmox, #ubuntu
В этом ролике поговорим о ключевых изменениях в новой версии Truenas Scale 24.10. Посмотрим на новый dashboard, как расширить пулы, а самое главное пощупаем docker, который появился вместо kubernetes.
Можно…
В этом ролике поговорим о ключевых изменениях в новой версии Truenas Scale 24.10. Посмотрим на новый dashboard, как расширить пулы, а самое главное пощупаем docker, который появился вместо kubernetes.
Можно…