Мне регулярно пишут и спрашивают на тему того, каким дистрибутивом 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
