6 июля 2019 года вышло очередное обновление популярного linux дистрибутива Debian. Это уже 10-й выпуск Debian под кодовым названием Buster. Я подробно расскажу, как выполнить обновление с предыдущего выпуска Debian 9 Stretch до Debian 10 Buster. Процесс обновления не сложный, выполняется штатными средствами с помощью apt.
https://serveradmin.ru/obnovlenie-debian-9-stretch-do-10-buster/

#статья #debian

Написал подробную инструкцию по установке Debian 10 на сервер. Постарался не банальные картинки визарда показать, а поделиться своим видением на современную разбивку диска и установку на программный рейд mdadm. Продемонстрировал выход из строя диска и его замену. Получился неплохой бюджетный вариант устойчивого к отказу диска сервера без аппаратного рейд контроллера. Можно использовать для гипервизора proxmox.
https://serveradmin.ru/kak-skachat-i-ustanovit-debian-10-buster/

#статья #debian

Разобрал по полочкам тему репозиториев в Debian. Пока статью не написал, сам толком не понимал, что там и как устроено. Копировал из раза в раз настройки. В Debian целая куча разных репозиториев и заморочек с софтом. Разные репы, разные ветки, разный софт, свободный, нет и т.д.
https://serveradmin.ru/nastrojka-repozitoriev-v-debian/

#статья #debian

Разобрал тему с настройкой времени в Debian. Вроде ничего нового и особенного, но тем не менее, некоторые вещи не знал, пока не стал разбираться. Например, по дефолту, управлением и синхронизацией времени сейчас в системах с systemd занимается этот самый systemd через юнит timesyncd.
https://serveradmin.ru/ustanovka-nastrojka-i-sinhronizacziya-vremeni-v-debian/

#статья #debian

У меня обычно по разрозненным шпаргалкам располагаются различные полезные команды. Решил собрать воедино все, что касается работы с дисками в debian, их настройка, добавление, подключение, расширение и т.д. и поделиться с вами. Все эти команды и приемы будут актуальны практически для любого дистрибутива linux.
https://serveradmin.ru/nastrojka-diskov-v-debian/

#статья #debian

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

​​Меня один человек попросил помочь найти установочный диск Debian старой версии. Конкретно 10.1. Я сначала удивился, что он сам не справился с этой задачей. Куча же зеркал Debian по миру раскиданы.

Сначала пошел на mirror.yandex.ru, так как обычно оттуда всё качаю и использую этот репозиторий в системе. Но там оказывается только последняя актуальная версия системы.

Сходил на официальный сайт Debian, там тоже только последняя актуальная версия доступна для загрузки. Для более старых стоит пометка:

We don't store/serve the full set of ISO images for all architectures, to reduce the amount of space taken up on the mirrors. You can use the jigdo tool to recreate the missing ISO images instead

Честно говоря, вообще не знаю, то такое jigdo tool. Разбираться с ней только ради того, чтобы скачать старый образ не хотелось. В итоге просто загуглил нужное имя файла и нашел зеркало, где лежат все старые образы последних двух версий Debian 9 и 10 - https://ftp.cae.tntech.edu/

Я не знаю, насколько можно доверять этому репозиторию. В связи с этим вопрос. А где вы достаёте старые версии Debian, если они вам нужны? У меня такой задачи никогда не стояло. Обычно беру самую свежую и нет проблем. Тем не менее, понимаю, что есть ситуации, где может понадобиться конкретная версия системы. Не думал, что это такая большая задача, сохранить где-то 10 iso образов хотя бы текущего релиза.

С Centos таких проблем никогда не было. Идешь на https://vault.centos.org/ и там всё есть.

#debian

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

Стоит упомянуть только об одной важной вещи. Если не знать про нее, то можно немного подвиснуть с решением проблемы. В 11-й версии немного изменился формат конфига с репозиториями sources.list. Теперь строка с security репой должна выглядеть вот так:

deb http://security.debian.org/ bullseye-security main

А раньше она была вот такой:

deb http://security.debian.org/ buster/updates main

Не знаю, что сподвигло на подобное изменение. Много релизов жили с одним форматом и всех всё устраивало. Теперь будет вот так.

Заодно я обновил и актуализировал свою статью про репозитории Debian. Там подробно разобраны и описаны все нюансы работы с репозиториями. Рассказано про типы реп, различные ветки, как формируются новые репы и куда уезжают старые, когда кончается поддержка. Когда писал статью, удивлялся, сколько же у Debian нюансов по этой теме. Сам обычно копировал конфиги с репозиториями и особенно не задумывался о том, что там каждая строка значит.

Помню как еще на заре своего админства по какому-то руководству из инета подключил sid репозиторий для установки софта и обновил из него систему. Потом долго мучался с зависимостями пакетов и глюками. Вернуться на stable уже не смог. Так что если админите Debian, с темой лучше один раз разобраться полностью.

#debian

​​Последние посты на тему прекращения поддержки Centos 8 и перехода на какую-то другую систему позволили мне окончательно убедиться в том, какую систему буду использовать в будущем. Я увидел, что большинство людей используют deb дистрибутивы - Debian и Ubuntu.

В итоге решил, что старые системы с Centos 8 переведу на Oracle Linux 8, но все новые системы отныне будут Debian. Соответственно, все статьи на сайте теперь будут посвящены только Debian. Все примеры в заметках будут тоже на основе Debian, где-то Ubuntu. С rpm-based дистрибутивами буду потихоньку прощаться. Зоопарк дистрибутивов делает неудобным их использование.

Мой путь в Unix получился таким: Freebsd -> Debian -> Centos -> Debian. К истокам не вернулся, к сожалению. С удовольствием бы пользовался Freebsd, но в наше время это мало реализуемо на практике.

Состояние неопределённости прекратилось, в том числе благодаря вам и вашим комментариям. Всем спасибо, всем Debian 😀

#debian #centos

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

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow

​​Ниже на картинке наглядное подтверждение того, что выбор дистрибутива Debian после прекращения поддержки Centos, был абсолютно верен. Всё вышло так, как я и предполагал. Появилось несколько форков, которые конкурируют друг с другом и создают разделение в сообществе.

Я выборочно взял трех провайдеров, где у меня есть учетные записи и виртуальные машины. И посмотрел, какие ОС они предлагают в своих шаблонах. Все три предложили разные замены Centos:
- Oracle Linux
- Rocky Linux
- AlmaLinux

Соответственно любой, кто выбрал что-то из этого списка у кого-то из хостеров получит проблему с тем, что шаблона с его системой там не будет. При этом тот же Debian или Ubuntu есть везде. Как и Freebsd. Пока непотопляемая тройка.

Так что мой выбор Debian как наиболее распространённой и консервативной системы с минимумом изменений пока оправдывает себя. Все новые установки теперь делаю только на ней, если выбор дистрибутива остаётся за мной.

Иногда использую Ubuntu, так как некоторый софт на ней быстрее и проще развернуть, но сам лично её не люблю за постоянные изменения от релиза к релизу, которые лично мне никаких удобств не добавляют, а только создают проблемы. Ну зачем постоянно менять установщик? На Debian он хуже что ли? Хотя не менялся уже лет 10.

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

#debian #centos

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

Для решения подобной проблему есть удобный инструмент - 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

Есть одна вещь, которая мне не нравится в Debian. Я всегда выполняю одну и ту же настройку сразу после установки системы. Не понимаю, кто придумал по умолчанию логи cron писать в общий системный лог /var/log/syslog. Это при том, что настройка для отдельного ведения журнала cron уже есть в конфиге rsyslog, но почему-то закомментирована. И настройка для логирования файла /var/log/cron.log уже есть в logrotate.

Если вы так же, как и я, любите, когда логи cron хранятся в отдельном файле, то сделайте следующее. Открываете на редактирование /etc/rsyslog.conf и раскомментируете строку:
cron.*                 /var/log/cron.log
Далее отключаем запись логов в общий файл. Добавляем cron.none в следующую строку:
*.*;auth,authpriv.none,cron.none    -/var/log/syslog
Перезапускаем rsyslog и cron:
# systemctl restart rsyslog cron

Проверяем, появился ли файл с логом.
# ls -l /var/log/cron.log

На всякий случай проверьте файл /etc/logrotate.d/rsyslog. Есть ли там строка с упоминанием файла /var/log/cron.log. Вроде должна быть. Не помню, чтобы я руками добавлял.

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

Я подзабыл, а в Ubuntu тоже логи cron в наследство от Debian пишутся в общий syslog? Кто-то делает подобную настройку или это мой бзик? Я после Centos никак не могу привыкнуть, что по дефолту нет этого лога.

#debian

​​Никогда не понимал, почему вывод информации об устанавливаемых пакетах в 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

В последнее время навводили кучу запретов на загрузку софта с IP адресов РФ. Я покажу на наглядном примере, как поднять свой deb репозиторий, наполнить его санкционным софтом и использовать в своей инфраструктуре.

Пример будет не гипотетический, а самый что ни на есть актуальный. Допустим, нам надо на парке серверов обновить filebeat от компании elastic, которая закрыла доступ к своим публичным репозиториям с территории РФ. Я включил прокси, скачал через браузер пакет filebeat-8.4.3-amd64.deb.

Далее идём на сервер с Debian, где будем настраивать локальный репозиторий с помощью aptly.
# apt install aptly

Создаём конфиг /etc/aptly.conf. Содержимое берём из документации, где меняем только rootDir и имя FileSystemPublishEndpoints.

{
 "rootDir": "/mnt/repo",
 "downloadConcurrency": 4,
 "downloadSpeedLimit": 0,
 "architectures": [],
 "dependencyFollowSuggests": false,
 "dependencyFollowRecommends": false,
 "dependencyFollowAllVariants": false,
 "dependencyFollowSource": false,
 "dependencyVerboseResolve": false,
 "gpgDisableSign": false,
 "gpgDisableVerify": false,
 "gpgProvider": "gpg",
 "downloadSourcePackages": false,
 "skipLegacyPool": true,
 "ppaDistributorID": "elk",
 "ppaCodename": "",
 "FileSystemPublishEndpoints": {
  "elkrepo": {
   "rootDir": "/var/www/aptly",
   "linkMethod": "symlink",
   "verifyMethod": "md5"
  }
 },
 "enableMetricsEndpoint": false
}

Создаём необходимые директории:
# mkdir -p /mnt/repo /var/www/aptly

Создаю репозиторий для Debian 11:
# aptly repo create -distribution="bullseye" elk
Копирую на сервер пакет и добавляю его в репозиторий:
# aptly repo add elk ~/filebeat-8.4.3-amd64.deb

Создаю gpg ключ для репозитория:
# gpg --default-new-key-algo rsa4096 --gen-key --keyring pubring
Real name: elkrepo

Публикуем репозиторий с этим ключом:
# aptly publish repo elk

Далее вам нужно поднять любой веб сервер и настроить через него доступ к директории /var/www/aptly. Если не хочется это делать, можно запустить сам aptly как веб сервер (дефолтный порт 8080):
# aptly serve

Он автоматом создаст и опубликует директорию /mnt/repo/public. Для удобства можно туда выгрузить публичный ключ:
# gpg --export --armor > /mnt/repo/public/elkrepo.asc

Можно зайти браузером на 8080 порт сервера и посмотреть содержимое репозитория вместе с gpg ключом.

Теперь идём на клиенты и подключаем репозиторий. Для этого создаём файл /etc/apt/sources.list.d/elk_repo.list:

deb http://10.20.1.56:8080 bullseye main

Обновляем пакеты и устанавливаем или обновляем filebeat:
# apt update && apt install filebeat

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

#debian #elk

​​В выступлении с DevOpsConf, про которое выйдет заметка вечером, увидел упоминание очень любопытной программы nfpm, с помощью которой можно собирать свои deb или rpm пакеты. Я посмотрел и нашёл её современной, простой и полезной. Сразу же попробовал на реальном примере. Результатом делюсь с вами.

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

Итак, ставим nfpm:
# echo 'deb [trusted=yes] https://repo.goreleaser.com/apt/ /' |
tee /etc/apt/sources.list.d/goreleaser.list
# apt update
# apt install nfpm

Готовим для него конфиг nfpm.yaml:

name: "tegu"
arch: "amd64"
platform: "linux"
version: "v1.27.0"
section: "default"
priority: "optional"
conflicts:
 - exim4
 - postfix
maintainer: "Kalmetov Igor <ik@mbk-lab.ru>"
description: |
 Tegu is the free mailserver.
vendor: "mbk-lab.ru"
homepage: "https://project.mbk-lab.ru"
contents:
- src: ~/tegu/bin/teguctl
 dst: /opt/tegu/bin/
- src: ~/tegu/sbin/tegu
 dst: /opt/tegu/sbin/
- src: ~/tegu/tegu.conf
 dst: /etc/tegu.conf
 type: config
- src: ~/tegu/tegu.service
 dst: /etc/systemd/system/tegu.service
 type: config
overrides:
 deb:
  scripts:
   preinstall: /root/tegu/preinstall.sh
   postinstall: /root/tegu/postinstall.sh

Для простоты и демонстрации возможностей nfpm некоторые вещи упростил и поместил в скрипты. Те же права доступа и создание каталогов можно сделать сразу в конфигурации nfpm, а не в скриптах.

Файлы tegu.service и tegu.conf взял из документации. Добавил свои скрипты для выполнения некоторых действий.

preinstall.sh:

#!/bin/bash
mkdir /opt/tegu
mkdir /opt/tegu/{bin,sbin,data,certs}
chown -R mail. /opt/tegu/{data,certs}
chgrp -R mail /opt/tegu/{bin,sbin}
chmod 750 /opt/tegu/{data,certs}
chmod -R 750 /opt/tegu/sbin
chmod -R 750 /opt/tegu/bin

postinstall.sh:

chown root.mail /etc/tegu.conf
chmod 640 /etc/tegu.conf
setcap CAP_NET_BIND_SERVICE=+eip /opt/tegu/sbin/tegu
systemctl enable tegu.service
systemctl start tegu.service

Собираем пакет:
# nfpm pkg --packager deb --target ~/
using deb packager...
created package: ~/tegu_1.27.0_amd64.deb

Пакет собран. Можно установить:
# dpkg -i ~/tegu_1.27.0_amd64.deb

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

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

#linux #debian #apt #tegu

На днях вышел релиз Debian 12 Bookworm. Для меня это не стало сюрпризом, так как недавно я уже смотрел эту версию и проверял, как проходит обновление с прошлого релиза. У меня уже довольно много серверов под управлением Debian, так что вопрос меня касается напрямую.

Решил не откладывать задачу на потом и сразу рассмотреть изменения новой версии. Я написал подробную статью с обновлением с 11-й версии на 12-ю. Постарался рассмотреть наиболее значимые моменты обновления в соответствии с рекомендациями самих разработчиков из заметки Upgrades from Debian 11 (bullseye).

⇨ https://serveradmin.ru/kak-obnovit-debian-11-do-debian-12-bookworm/

Из основных нововведений, помимо обновления пакетов, я отметил следующие:

◽В установочные образы включили некоторые прошивки из репозитория non-free. Это сделано для лучшей поддержки железа во время установки. Debian всегда очень внимательно относился к проприетарному софту, выделяя его в отдельный репозиторий non-free. В этом релизе решили сделать некоторые исключения. Поэтому добавлен ещё один репозиторий для проприетарных прошивок non-free-firmware.

◽В Debian 12 добавлен пакет ksmbd-tools, который реализует функциональность файлового сервера на базе протокола SMB3. Сервер работает на базе модуля ядра Linux. Подобная реализация более эффективна с точки зрения производительности, потребления памяти и интеграции с расширенными возможностями ядра. При этом ksmbd не претендует на полноценную замену Samba. Скорее как расширение для неё.

◽По умолчанию не используется rsyslog для записи системных логов. Вместо этого предлагают использовать journalctl для просмотра логов systemd. Если хотите (а мы хотим) по старинке системные логи в текстовом виде в /var/log, установите пакет system-log-daemon.

◽Из дистрибутива выпилили утилиту which, которая объявлена устаревшей. Вместо неё предлагают использовать type. Это приведёт к поломке многих скриптов, где часто используют which для определения полного пути к бинарнику. Не забудьте установить вручную whitch, если она у вас используется.

◽Из репозиториев убрали пакеты для Asterisk. Не нашлось желающих их поддерживать, а сами разработчики астера не занимаются поддержкой пакетов в принципе.

С полным списком можете ознакомиться в официальной новости или переводе на opennet. За что лично мне нравится Debian, так это за его стабильность. В нём мало каких-то революционных изменений ради изменений. К примеру, сколько я знаю Debian, ещё со времён 6-й версии, у него не менялся интерфейс установщика. В этом просто нет смысла. Всё, что нужно в плане функциональности, там есть. Нет смысла менять то, что хорошо работает.

Я один свой сервер уже обновил, всё прошло штатно. Остальной прод торопиться обновлять не буду. Подожду месячишко, другой.

Скоро наверное Proxmox свою новую версию выкатит. Он обычно подгоняет свои релизы под релизы Debian. Я уже видел инфу про появление 8-й беты.

#debian