Как устроена навигация в автомобилях Tesla. В чем трудности поиска пути по земли русской?

C 2018 года все счастливые обладатели Tesla в России получили обновление Европейской навигации в которой России уже не было, официально это объясняется поддержанием баланса веса карт и удалением регионов, не входящих в зону официального обслуживания.

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

Тесла использует для построения маршрутов Valhalla -это механизм маршрутизации с открытым исходным кодом и сопутствующие библиотеки для использования с данными OpenStreetMap.

Вальхалла - это не только пантеон германских Богов и "чертог мёртвых ", но и отличный движок для построения маршрутов с дополнительными инструментами и модульной структурой, API на основе C++, с возможностью перекрестной компиляции различных фрагментов. И да, все это open source https://github.com/valhalla/valhalla.

Работает на Linux и Mac OS и частично на Windows.

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

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

Baldr - базовые структуры данных для доступа и кэширования данных маршрута.

Sif - библиотека, используемая при расчете стоимости узлов графа. Это может быть использовано в качестве входных данных для Loki и Thor.

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

Mjolnir - Инструменты для превращения открытых данных в части графа Valhalla.

Loki - библиотека, используемая для поиска участка графа и корреляции входных местоположений с объектом внутри участка. Эта коррелированная сущность (ребро или вершина) может использоваться в качестве входных данных для Thor.

Meili - библиотека, используемая для сопоставления карт.

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

Odin - библиотека, используемая для создания маневров в пути. Этот набор информации о направлениях может использоваться в качестве входных данных для Tyr.

Tyr - сервис, используемый для обработки http-запросов для маршрута, связывающегося со всеми другими API valhalla. Tyr форматирует вывод из Odin.

Установка

Если у Вас Ubuntu 20.04 отличный гайд по установке.

Здесь можно скачать карты, выбрав нужные регионы.

Для ЦФО РФ

curl -O http://download.geofabrik.de/russia/central-fed-district-latest.osm.pbf

Рендерим карты

valhalla_build_tiles -c ./conf/valhalla.json central-fed-district-latest.osm.pbf

Запускаем

valhalla_service ~/valhalla/scripts/conf/valhalla.json 2

Давайте найдем маршрут на автомобиле из Москвы в Подольск

curl http://localhost:8002/route \--data '{"locations":[              {"lat":55.7522,"lon":37.6156},              {"lat":55.4242,"lon":37.5547}           ],         "costing":"auto"        }' | jq '.'

В ответ получаем JSON с узловыми токами маневров.

Файл навигации в Тесла

Я обратился https://teesla.ru/ и мне передали файл с европейской навигацией из Тесла. Весит файл около 8гб и на мое удивление содержит вовсе не карты, а уже проложенные пути.

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

Для адресов используются данные из карт Tomtom

Файл карт в файловой системе Squashfs (.sfs)

Последние 2кб очень странные, в них и вся соль. Файлы подписаны ключом. Шифрование AES.

При загрузке карт в машину, Тесла проверяет подпись поэтому модифицированные карты не удалось загрузить.

P.S.

Можно ли подписать карты? Найти ключ и порядок S-box? Тесла на Тегра хранят файл навигации на отдельной карте памяти в MCU. Тесла на Intel хранят файл навигации на в основной eMMC. С картой памяти все просто, разбираем половину торпеды, вытаскиваем из MCU, заливаем дамп с картами и вставляем обратно, с eMMC не так все однозначно. Если карты просто залить на чип eMMC, апдейтер в автомобиле с живыми сертификатами загрузит обновление и заменит их.

От cебя готов предоставить приз целый день аренды самой заряженной Tesla model 3 Performance за способ генерации и загрузки карт в Tesla model 3 с РФ. Пишите в личку.

14 лет назад, в июне 2007го, Алекс Горбачев, в то время еще CTO Pythian, основал BAAG Party - Battle Against Any Guess - инициативу против любых гаданий при решении технических проблем. Уже тогда это становилось большой проблемой: все чаще на форумах и публичных мейл-листах на вопросы о специфических проблемах, вместо запроса необходимых технических деталей, приходили ответы в духе "а попробуйте то, если не поможет - попробуйте это", "я когда-то видел похожее, мне помогло XXX", "а мне ХХХ не помогло, зато помогло YYY". Рождались различные мифы и порождали еще большее новых, оттуда и всякое "шаманство" и "танцы с бубном"(частично и "работает - не трожь"). Все это вполне объяснимо: сложность ПО и железа экспоненциально увеличивается; количество недостоверной информации а-ля "for dummies" в сети растет как снежный ком; IT отрасли нужно все больше и больше работников на "конвейеры" - "бери больше, кидай дальше". Появление #BAAG тогда было абсолютно закономерным и неотвратимым, но насколько она актуальна сейчас? Почему после ее расцвета и популярности в течение нескольких лет, она в забвении? Что и когда должно появиться ей на замену на данный период развития IT?

Для начала я хотел бы процитировать отрывок из интервью Алекса:

Whats wrong with making an educated guess? We have limited data, limited knowledge, limited experience, limited tools, and limited time. Can we ever really know?

Yes we can! At least, we should strive to know....
Most real life problems can be solved with the knowledge that is available in the public domain, using data that is possible to extract by applying the right experience and tools and taking enough time to do the job properly.
It is the purpose of the Battle to promote the importance of knowledge fighting ignorance, selecting the right tools for the job, popularizing the appropriate troubleshooting techniques, gaining experience, and learning to take time to diagnose the issue before applying the solution. One might think that the BAAG motto is a bit extreme but thats a political decision to emphasize the importance of the goal.
...
When I established the Battle Against Any Guess Party, a number of people argued that guesswork is the cruel reality with Oracle databases because sometimes we do hit the wall of the unknown. The argument is that at such point, there is nothing else left but to employ guesswork. Several times people have thrown out the refined term educated guess. However, I would argue that even in these cases, or especially in these cases, we should be applying scientific techniques. Two good techniques are deduction and induction.

Времена меняются: так же как и когда-то прошло время энциклопедистов, придет время и в IT, когда объем необходимых знаний даже для траблшутинга от верхнеуровневых процедур до сисколлов ядра превысит критическую точку. Все еще осложняется тем, что количество качественной достоверной информации относительно низкосортной писанины неуклонно уменьшается. Типичная ситуация сейчас: человека встречает проблему, гуглит ее, приходит на какой-нибудь стековерфлоу и берет решение из ответа, помеченного как правильный. Ладно еще, если это помогло, а если не помогло, то начинается перебор - вторая ссылка, третья ссылка, и тд, или создается новый вопрос и тогда перебор по ответам... Какова же вероятность выбора оптимального решения в таких случаях? Или даже проще: являются ли люди из топа по ответам экспертами в областях, в которых они отвечают? Не будет ли порожден очередной миф? Причем, я одобряю и полностью поддерживаю терпение, широту знаний и любознательность таких энтузиастов! IT уже давно не удел только энтузиастов, теперь полно людей, которые не любят свою работу, и их палкой не заставить что-то прочитать, или сотрудников загоняют настолько, что у них просто не остается ни времени, ни сил на самообразование.

В сложившейся ситуации, очевидно, что от гаданий и метода проб и ошибок уже никуда не деться. Так может уже уйти от категоричного Battle Against Any Guess, к чему-то более терпимому? Например, Battle Against Any Non-educated Guess или на худой конец Guess Carefully? Или уже смириться с этим и просто надеяться на светлое будущее? Ведь в целом, несмотря на всю печальность ситуации и страшные (но уже набившие оскомину) аналогии с врачами, все не так страшно: проблемы так или иначе решаются, а в сложных критичных областях все намного серьезнее и уже так не гадают...

Современный мир ПО содержит настолько много слоёв, что оптимизации могут быть в самых неожиданных местах. Знакомьтесь - год 2000, проект HP Dynamo. Это эмулятор процессора PA-8000, работающий на этом же процессоре PA-8000, но с технологией JIT. И реальные программы, запускающиеся в эмуляторе - в итоге работают быстрее, чем на голом процессоре.

td;dr - всё сказано в заголовке

Программистам из HP Labs стало интересно, а что будет, если написать оптимизирующий JIT компилятор под ту же платформу, на которой он работает. Работа заняла несколько лет. Под эмулятором можно было запускать немодифицированные родные бинари. И результаты оказались несколько неожиданными.

В эмуляторе они искали "hot paths" и оптимизировали ход исполнения кода. Таким образом уменьшались расходы на джампы, вызов функций, динамических библиотек, оптимизации работы с кешем процессора. Результаты повышения производительности доходили до +22%, в среднем по тестам получалось +9%.

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

Если кому интересны подробности:

1. http://cseweb.ucsd.edu/classes/sp00/cse231/dynamopldi.pdf
2. https://stackoverflow.com/questions/5641356/why-is-it-that-bytecode-might-run-faster-than-native-code/5641664#5641664
3. https://en.wikipedia.org/wiki/Just-in-time_compilation

Да, понимаю, что это игра про учёных, но это не игра про немого учёного с монтировкой с цифрой 3, которую все ждут. Что вышло за 4 года разработки.

Официальное описание: Научная станция в глубоком космосе перестала отвечать на запросы. Что там произошло? Вы агент, прибывший выяснить, что случилось и Ваша задача спасти важное открытие, сделанное на станции.

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

Заправьте свой корабль радиоактивным топливом и спасите ученых. Берегите себя, науку и удачи!

Это ретро экшен, требующий достаточной быстроты, либо ловкости, либо хитрости от игрока. Есть несколько тактик прохождения игры. Кроме арсенала в 10 видов оружия, каждое из которых накладывает особый эффект на врага и имеет несколько режимов стрельбы, есть ещё и хитрость в виде ловушек или предметов сильно отвлекающих противника. некоторых настолько что игрок будет почти невидим для врагов. Даже на нормальной сложности игра не будет лёгкой прогулкой по которой игрока будут водить за ручку и обьяснять Press F to Win. Однако если вам игра покажется слишком лёгкой уровень сложности можно повысить.

В самой игре заложена и пара "пасхалок" напоминающих о спектруме. Я не скажу где они однако одна из них содержит пару обьектов из Boulder dash, а другая ещё что-то.

Ключевые обновления:

• Добавлен режим хотсита - кооп (. затем kp9) и версус (. затем kp7). (Игра на 2 клавиатурах и/или джойстиках). Cетевая игра увы возможна только через Steam remote play.

• Все почти враги теперь анимированы (новое видео пока не готово)

• Внешний интерфейс (USER GUI) доработан. (Инвентарь, выбранное оружие, датчик жизни, кулдаун, селектор оружия.)

• Встроенная игровая справка по F2 с описанием тактики поведения и арсенала.

Ключевые особенности

• Редактор карт поддерживает импорт карт M2K (mission 2000), Rescue+ с реального ZX-Spectrum. Карты будут работать если их копировать программой HOBETA.

• Мультиязычность и кроссплатформенность.

• Высокая скорость работы даже на устаревших компьютерах.

Подсказка: Максимально просто игру можно пройти вдвоем - Один из игроков должен выбрать ученого при начале совместной игры.

Игра нетребовательная идёт почти на всём. Требования: 64бит и OpenGL 3.3 и хотя бы 30 мб места.

Steam Ранний доступ.

Все списки обновлений переводятся также на 3 языка как и сама игра. Прочесть можно на страничке игры

Я ранее писал статью на DTF и если кто хочет просто попробовать игру Reskue или M2K или Colony (очень ранняя версия) может скачать их ниже.

Видео новее пока нет. если только про кооператив и версус ссылка под видео. С тех пор игра была сильно переработана но я пока не осилил трейлер.

Хотсит на русском.

Новый трейлер на польском.

Я на вопросы иногда делаю выпуски видеоответов. Реже чем надо было бы, но делаю. https://www.youtube.com/watch?v=JJAe2b-kTgs - Руководство о портировании готовой игры на Love в Android APK (с подписью) для Linux. В блоге разработчика (devblog) бывают и арты и рисунки и другая всячина.

Игра написана с нуля и сохранившая в основном идею оригинала (Rescue od Mastertronic) и схожесть с Spectrum играми (тайлы, цветовая гамма, некоторая хардкорность геймплея и некоторые команды в Lua движке.). От оригинальной игры не используется ничего, перерисовано все что возможно. Изначально я делал ремейк собственной игры M2K (mission2000), затем понял что на основе движка могу сделать новую игру что и начал в 2019, вдохновили меня в коллективе confa-gd на конкурсе Джем победы на это. Канал по игре.

C чего всё начиналось:

Это оказался прекрасный фундамент для применения множества идей как Sci-fi так и просто современных удобств геймплея каждую из которых пришлось делать самому, т.к. движок мой авторский на Love framework. Я постарался бережно развить идею так как ранее с ограничениями платформы ее развить было бы значительно сложнее. Я с трудом нашел нескольких художников и аниматоров и за ещё 2 года и 16К получилась эта игра. Отдельная история и целая лекция получилась по работе со Steamworks чтобы игра попала в магазин, это заняло целых полгода в основном доработки тексту. Я даже не думаю что она вообще когда то отобьется и будет кормить меня и принесет мне хоть что то. мне просто хотелось возродить частичку классики так как я её вижу и сделать ее доступной всем.

Также я веду небольшой ютуб и телеграм каналы без мемасиков и приколов посвященный Linux для домашнего использования. Сборка в основном для тестирования Windows игр предназначена. Сам я выбрал Mint c Mate DE немного новостей немного взаимопомощи.

N.B. Людям, которые ждут, что один человек почти в одно лицо накодит им Ведьмака 3 в 3D за денек, прошу выйти из чата. Этим методом получатся только игры для Gry z kosza (польская передача об очень плохих играх).

Мне просто хочется, чтобы в эту игру можно было сыграть и через много лет спустя, я думаю Steam с нами всеми надолго и игра там точно проживёт много лет. Да название я написал в духе названия mortal kombat. А почему нет?

Также я время от времени обновляю код движка на github. У меня там несколько проектов.

Давно ничего не писал, поэтому разбавим конец пятницы простыми, но не всегда очевидными иcканиями в Nginx.

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

Поскольку переменные вычисляются только в момент использования, само по себе наличие даже большого числа объявлений переменных map не влечёт за собой никаких дополнительных расходов на обработку запросов.

И здесь важным является не только, то что "map не влечёт за собой никаких дополнительных расходов на обработку запросов", а и то, что "переменные вычисляются только в момент использования".

Как известно, конфиг Nginx, в основном, декларативен. Это касается и директивы map, и, не смотря на то, что она расположена в контексте http, её вычисление не происходит до момента обработки запроса. То есть при использовании результирующей переменной в контекстах server, location, if и т.п. мы "подставляем" не готовый результат вычисления, а лишь "формулу" по который этот результат будет вычислен в нужный момент. В этой конфигурационной казуистике не возникает проблем до того момента, пока мы не используем регулярные выражения. А именно регулярные выражения с выделениями. А ещё точнее, регулярные выражения с неименованными выделениями. Проще показать на примере.

Допустим у нас есть домен example.com с множеством поддоменов 3-го уровня, а-ля ru.example.com, en.example.com, de.example.com и т.д., и мы хотим их перенаправить на новые поддомены ru.example.org, en.example.org, de.example.org и т.п. Вместо того чтобы описывать сотни строк редиректов мы поступим вот так:

map $host $redirect_host {  default "example.org";  "~^(\S+)\.example\.com$"  $1.example.org;}server {    listen       *:80;    server_name  .example.com;  location / {        rewrite ^(.*)$ https://$redirect_host$1 permanent;    }

Здесь мы ошибочно ожидали, что при запросе ru.example.com произойдет вычисление регулярки в map и, соответственно, попав в location переменная $redirect_host будет содержать значение ru.example.org, однако на деле это не так:

$ GET -Sd ru.example.comGET http://ru.example.com301 Moved PermanentlyGET https://ru.example.orgru

Оказалось, что на момент исполнения запроса наша переменная равна ru.example.orgru. Всё из-за того, что мы пренебрегли предупреждением "переменные вычисляются только в момент использования", а в нашем rewrite оказалась некая регулярка вложенная в регулярку.

Самый простой вариант решения - не использовать regexp одновременно и в map и в месте вычисления переменной, например, для данного конкретного случая это может выглядеть так:

map $host $redirect_host {  default "example.org";  "~^(\S+)\.example\.com$"  $1.example.org;}server {    listen       *:80;    server_name  .example.com;    location / {        return 301 https://$redirect_host$request_uri;    }}

Но что делать, если альтернативного решения без регулярок нет (ну или просто очень хочется).
Пробуем использовать именованные выделения в map:

map $host $redirect_host {  default "example.org";  "~^(?<domainlevel3>\S+)\.example\.com$"  $domainlevel3.example.org;}server {    listen       *:80;    server_name  .example.com;    location / {        rewrite ^(.*)$ https://$redirect_host$1 permanent;    }}

Попытка не увенчалась успехом:

$ GET -Sd ru.example.comGET http://ru.example.com301 Moved PermanentlyGET https://ru.example.orgru

так как наше неименованное выделение $1 получит результат именованного $domainlevel3. То есть необходимо использовать именованные выделения в обеих регулярках:

map $host $redirect_host {  default "example.org";  "~^(?<domainlevel3>\S+)\.example\.com$"  $domainlevel3.example.org;}server {    listen       *:80;    server_name  .example.com;    location / {        rewrite ^(?<requri>.*)$ https://$redirect_host$requri permanent;    }}

И теперь всё работает как ожидалось:

$ GET -Sd ru.example.comGET http://ru.example.com301 Moved PermanentlyGET https://ru.example.org/

Acme.sh - скрипт, позволяющий без особых проблем получать let's encrypt сертификаты очень разными способами. В данной статье я разберу как получать сертификаты через DNS api, но этим уже никого не удивишь, поэтому расскажу про метод DNS alias, он свежий (всего 3 года) и интересный. А так же про автоматизацию на Ansible и немного про мониторинг сертификатов.

Видеоверсия

Режимы acme.sh получения сертификатов прямо на целевом сервере

• Webroot

• Nginx\Apache

• Stanalone

Режимы хорошие и удобные, когда у вас один - два сервера и можно просто на каждый установить acme.sh. Когда количество серверов, которым нужно TLS, переваливает за десяток, удобнее начать использовать wilcard сертификаты и выделить отдельный сервер для получения и распространения сертификата\ов. Получить wildcard сертификат можно только через подтверждение владения DNS зоной. DNS режимов несколько:

• DNS manual

• DNS API

• DNS alias

Все примеры буду показывать на моём личном домене и установленном локально acme.sh.

DNS manual mode

Manual режим работает супер просто. Запускаем acme.sh с флагом --dns

acme.sh --issue --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please

koala@x220:~$ acme.sh --issue --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please[Ср мая  5 14:52:29 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Ср мая  5 14:52:29 MSK 2021] Creating domain key[Ср мая  5 14:52:29 MSK 2021] The domain key is here: /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key[Ср мая  5 14:52:29 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 14:52:29 MSK 2021] Getting domain auth token for each domain[Ср мая  5 14:52:32 MSK 2021] Getting webroot for domain='*.itdog.info'[Ср мая  5 14:52:32 MSK 2021] Add the following TXT record:[Ср мая  5 14:52:32 MSK 2021] Domain: '_acme-challenge.itdog.info'[Ср мая  5 14:52:32 MSK 2021] TXT value: 'QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8'[Ср мая  5 14:52:32 MSK 2021] Please be aware that you prepend _acme-challenge. before your domain[Ср мая  5 14:52:32 MSK 2021] so the resulting subdomain will be: _acme-challenge.itdog.info[Ср мая  5 14:52:32 MSK 2021] Please add the TXT records to the domains, and re-run with --renew.[Ср мая  5 14:52:32 MSK 2021] Please add '--debug' or '--log' to check more details.[Ср мая  5 14:52:32 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

--issue - запрос на получение

--dns без аргумента - режим ручного DNS

--yes-I-know-dns-manual-mode-enough-go-ahead-please - интересное решение проблемы, когда люди не понимают что такое ручной режим

Он выдаёт TXT запись, которую нам необходимо добавить в наш dns хостинг, в данном случае это _acme-challenge.itdog.info TXT QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8

Ручной он потому что, мы вручную добавляем эту запись.

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

После добавления записи проверяем начала ли она резолвится на гугловом dns

koala@x220:~$ dig -t txt _acme-challenge.itdog.info @8.8.8.8; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> -t txt _acme-challenge.itdog.info @8.8.8.8;; ANSWER SECTION:_acme-challenge.itdog.info. 1798 IN    TXT    "QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8"

Она резолвится, а значит можно получать сертификат

koala@x220:~$ acme.sh --renew --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please[Ср мая  5 14:58:08 MSK 2021] Renew: '*.itdog.info'[Ср мая  5 14:58:09 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Ср мая  5 14:58:09 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 14:58:09 MSK 2021] Getting domain auth token for each domain[Ср мая  5 14:58:09 MSK 2021] Verifying: *.itdog.info[Ср мая  5 14:58:13 MSK 2021] Success[Ср мая  5 14:58:13 MSK 2021] Verify finished, start to sign.[Ср мая  5 14:58:13 MSK 2021] Lets finalize the order.[Ср мая  5 14:58:13 MSK 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/121...'[Ср мая  5 14:58:15 MSK 2021] Downloading cert.[Ср мая  5 14:58:15 MSK 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/042...'[Ср мая  5 14:58:16 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Ср мая  5 14:58:16 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Ср мая  5 14:58:16 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Ср мая  5 14:58:16 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Ср мая  5 14:58:16 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer 

После этого TXT запись можно удалить.

Теперь есть ключ и сертификат, который будет действителен 3 месяца. Обновить сертификат можно будет через 2 месяца, let's enctypt даёт запас времени и если у вас вдруг что-то сломается, будет целый месяц чтобы починить и обновить сертификат.

И да, обновляется только сертификат, ключ остаётся таким, какой был выдан в первый раз. Обратите внимание на даты создания файлов, особенно *.example.com.key

# ls -l --time-style=+%Y-%m-%d \*.example.com/total 28-rw-r--r-- 1 root root 1587 2021-04-15 ca.cer-rw-r--r-- 1 root root 3433 2021-04-15 fullchain.cer-rw-r--r-- 1 root root 1846 2021-04-15 *.example.com.cer-rw-r--r-- 1 root root  719 2021-04-15 *.example.com.conf-rw-r--r-- 1 root root  980 2021-04-15 *.example.com.csr-rw-r--r-- 1 root root  211 2021-04-15 *.example.com.csr.conf-rw-r--r-- 1 root root 1675 2019-04-10 *.example.com.key

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

DNS API mode

Как это работает? Принцип действия тот же самый что у manual, только acme.sh сам вносит и удаляет TXT запись с помощью API вашего dns провайдера.

Под DNS хостингом и DNS провайдером я буду иметь в виду сервис, в который вносятся DNS записи. Это может быть и DNS хостинг, который есть почти у каждой компании, торгующей доменами (namecheap, beget итд) или как отдельный сервис за деньги (Amazon Route 53, ClouDNS итд), или же ваш собственный сервис развернутый с помощью BIND, PowerDNS итд.

У каждого DNS провайдера свой не стандартизированный API и их поддержка в acme.sh реализована отдельными скриптами. Список всех поддерживаемых провайдеров находится тут https://github.com/acmesh-official/acme.sh/wiki/dnsapi

Для каждого написано как пользоваться и пример. Если вашего провайдера или сервиса нет в списке, можно написать свой скрипт, но не спешите открывать vim, дождитесь третьего способа.

Работу этого режима покажу на примере хостинга DNS у namecheap.

Для каждого DNS провайдера свои настройки, где-то нужно просто включить API и сгенерировать токен, где-то бывает посложнее, например для namecheap нужно ещё внести IP в allow list. Включаем API и сразу генерируется token, добавляем IP в список.

Теперь на локальной машине нужно настроить доступ к API

export NAMECHEAP_USERNAME="USERNAME"export NAMECHEAP_API_KEY="TOKEN"export NAMECHEAP_SOURCEIP="MY-IP"

Отступление про дополнительные флаги force и test. Будем использовать флаг -f (--force), что бы наши сертификаты генерировались заново, т.к. acme.sh видит уже сгенерированные сертификаты при их наличии не будет заново получать. Можно конечно просто сделать rm -rf ~/.acme.sh/domain/ вместо этого. Так же будем использовать флаг --test, что бы лишний раз не нагружать продакшн сервера let's encrypt. Вот такое сообщение мы получим, если после подтверждения в manual режиме попробуем другой режим.

[Ср мая 5 16:39:31 MSK 2021] *.itdog.info is already verified, skip dns-01.

Команда получения через API выглядит таким образом

acme.sh --issue --dns dns_namecheap -d *.itdog.info --test

Здесь после --dns мы добавляем имя провайдера.

Запускаем acme.sh

koala@x220:~$ acme.sh --issue --dns dns_namecheap -d *.itdog.info --test[Ср мая  5 16:48:05 MSK 2021] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory[Ср мая  5 16:48:06 MSK 2021] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory[Ср мая  5 16:48:06 MSK 2021] Creating domain key[Ср мая  5 16:48:07 MSK 2021] The domain key is here: /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key[Ср мая  5 16:48:07 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 16:48:07 MSK 2021] Getting domain auth token for each domain[Ср мая  5 16:48:09 MSK 2021] Getting webroot for domain='*.itdog.info'[Ср мая  5 16:48:10 MSK 2021] Adding txt value: nCH4tBWCkSVn76301f2SdJqCAzmtXvzQAB_Ag8hURLo for domain:  _acme-challenge.itdog.info[Ср мая  5 16:48:15 MSK 2021] The txt record is added: Success.[Ср мая  5 16:48:15 MSK 2021] Let's check each DNS record now. Sleep 20 seconds first.[Ср мая  5 16:48:36 MSK 2021] You can use '--dnssleep' to disable public dns checks.[Ср мая  5 16:48:36 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck[Ср мая  5 16:48:36 MSK 2021] Checking itdog.info for _acme-challenge.itdog.info[Ср мая  5 16:48:37 MSK 2021] Domain itdog.info '_acme-challenge.itdog.info' success.[Ср мая  5 16:48:37 MSK 2021] All success, let's return[Ср мая  5 16:48:37 MSK 2021] Verifying: *.itdog.info[Ср мая  5 16:48:41 MSK 2021] Success[Ср мая  5 16:48:41 MSK 2021] Removing DNS records.[Ср мая  5 16:48:41 MSK 2021] Removing txt: nCH4tBWCkSVn76301f2SdJqCAzmtXvzQAB_Ag8hURLo for domain: _acme-challenge.itdog.info[Ср мая  5 16:48:46 MSK 2021] Removed: Success[Ср мая  5 16:48:46 MSK 2021] Verify finished, start to sign.[Ср мая  5 16:48:46 MSK 2021] Lets finalize the order.[Ср мая  5 16:48:46 MSK 2021] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/193...'[Ср мая  5 16:48:48 MSK 2021] Downloading cert.[Ср мая  5 16:48:48 MSK 2021] Le_LinkCert='https://acme-staging-v02.api.letsencrypt.org/acme/cert/fa62...'[Ср мая  5 16:48:49 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Ср мая  5 16:48:49 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Ср мая  5 16:48:49 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Ср мая  5 16:48:49 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Ср мая  5 16:48:49 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer

В логе прям видно, что acme.sh добавляет TXT запись, ждёт немного, проверяет запись через доверенные DNS сервера, удаляет запись и скачивает сертификаты с ключом.

После первого запуска через API, acme.sh заносит env переменные c доступами к API себе в файл ~/.acme.sh/account.conf и вам не нужно каждый раз их экспортировать.

Отлично, получение автоматизировали, всё вроде классно. Но у этого метода есть свои недостатки:

• Если никто не написал скрипта для вашего провайдера\сервиса, то нужно либо писать, либо переезжать на другой провайдер

• А есть ли у вашего провайдера API?

• Поразмышляем немного об безопасности. Вот у меня в "открытую" лежит полный доступ к редактированию моего домена, если он каким-то образом попадёт в чужие руки, эти руки могут сделать что угодно. Эту проблему можно решить ограничим доступа в API, например по токену можно только добавлять\удалять txt записи _acme-challenge. Есть ли такая возможность у вашего провайдера? Я не встречал такого, наверное есть у какого-нибудь AWS конечно. Обычно уже хорошо если есть API, а токен один и даёт полный доступ

• У вас несколько доменов на разных провайдерах (сочувствую). Тут конечно можно настроить каждое API и сделать для каждого провайдера отдельный запуск acme.sh со своими переменными, но мне кажется это не очень удобным. Тем более если у одного из них отсутствует API или скрипт

• Кто-то просто не любит, что бы в DNS постоянно лазил какой-то скрипт и что-то добавлял\удалял

DNS aliase mode

Это модернизированный режим DNS API.

Идея такая: Есть технический домен, через добавления TXT записей на котором мы подтверждаем владение основным доменом. т.е. acme.sh смотрит CNAME запись у основного домена, видит "перенаправление" на технический домен и идёт к нему проверять TXT запись. А дальше всё как в режиме DNS API.

Разберём последовательно. Для демонстрации я купил домен tech-domain.club, он выступает в качестве технического домена. В моём примере основной домен itdog.info располагается на namecheap, а техничский tech-domain.club я делегирую на Hetzner DNS, таким образом операции с записями будут производиться через API Hetzner'a.

В записях основного домена мы добавляем CNAME запись, которая указывает на технический домен

_acme-challenge CNAME _acme-challenge.tech-domain.club

Для провайдера с техническим доменом мы настраиваем доступ к API.

Экспортируем токен Hetzner export HETZNER_Token="TOKEN"

Команда выглядит так (-f и --test опять же для примера)

acme.sh --issue -d *.itdog.info --challenge-alias tech-domain.club --dns dns_hetzner -f --test

koala@x220:~$ acme.sh --issue -d *.itdog.info -d itdog.info --challenge-alias tech-domain.club --dns dns_hetzner -f --test[Пт мая  7 13:40:11 MSK 2021] Domains have changed.[Пт мая  7 13:40:11 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Пт мая  7 13:40:11 MSK 2021] Multi domain='DNS:*.itdog.info,DNS:itdog.info'[Пт мая  7 13:40:11 MSK 2021] Getting domain auth token for each domain[Пт мая  7 13:40:15 MSK 2021] Getting webroot for domain='*.itdog.info'[Пт мая  7 13:40:15 MSK 2021] Getting webroot for domain='itdog.info'[Пт мая  7 13:40:15 MSK 2021] Adding txt value: Zlrij9n4y5QXfH6yx_PBn45bgmIcT70-JuW2rIUa6lc for domain:  _acme-challenge.tech-domain.club[Пт мая  7 13:40:16 MSK 2021] Adding record[Пт мая  7 13:40:17 MSK 2021] Record added, OK[Пт мая  7 13:40:20 MSK 2021] The txt record is added: Success.[Пт мая  7 13:40:20 MSK 2021] Let's check each DNS record now. Sleep 20 seconds first.[Пт мая  7 13:40:41 MSK 2021] You can use '--dnssleep' to disable public dns checks.[Пт мая  7 13:40:41 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck[Пт мая  7 13:40:41 MSK 2021] Checking itdog.info for _acme-challenge.tech-domain.club[Пт мая  7 13:40:42 MSK 2021] Domain itdog.info '_acme-challenge.tech-domain.club' success.[Пт мая  7 13:40:42 MSK 2021] All success, let's return[Пт мая  7 13:40:42 MSK 2021] *.itdog.info is already verified, skip dns-01.[Пт мая  7 13:40:42 MSK 2021] Verifying: itdog.info[Пт мая  7 13:40:46 MSK 2021] Success[Пт мая  7 13:40:46 MSK 2021] Removing DNS records.[Пт мая  7 13:40:46 MSK 2021] Removing txt: Zlrij9n4y5QXfH6yx_PBn45bgmIcT70-JuW2rIUa6lc for domain: _acme-challenge.tech-domain.club[Пт мая  7 13:40:50 MSK 2021] Record deleted[Пт мая  7 13:40:50 MSK 2021] Removed: Success[Пт мая  7 13:40:50 MSK 2021] Verify finished, start to sign.[Пт мая  7 13:40:50 MSK 2021] Lets finalize the order.[Пт мая  7 13:40:50 MSK 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/121...'[Пт мая  7 13:40:52 MSK 2021] Downloading cert.[Пт мая  7 13:40:52 MSK 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/04e...'[Пт мая  7 13:40:53 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Пт мая  7 13:40:53 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Пт мая  7 13:40:53 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Пт мая  7 13:40:53 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Пт мая  7 13:40:53 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer 

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

Кстати, если вам нужно в одном файле иметь несколько сертификатов, например и itdog.info и wildcard *.itdog.info, то просто перечислите их с -d, например

acme.sh --issue --challenge-alias tech-domain.club --dns hetzner -d *.itdog.info -d itdog.info

Это правило действует и для других методов.

И так, что даёт нам этот режим:

• Если у вашего провайдера нет API или лень писать скрипт, возьмите технический домен, делегируйте его на сервис, который поддерживает acme.sh

• Если у вашего провайдера нет настройки прав для доступа через API, то технический домен тоже выручает. В случае, если наш token утечёт, у злоумышленника будет доступ только к вашему техническому домену, и если вы его используете только для acme.sh, то максимум что сможет сделать злоумышленник - получить ключ и сертификат для вашего домена. Это тоже неприятно и можно использовать, но это совершенно другой уровень угрозы, по сравнению с полным доступом к доменной зоне

• В ситуации с кучей доменов на одном или нескольких провайдерах, жизнь так же становится проще, когда все они просто имеют CNAME запись

Есть так же режим domain-alias, он даёт возможность использовать не _acme-challenge запись, а кастомную, подробности можно прочитать в документации

Автоматизация получения и распространения сертификатов

Мы получили сертификаты, лежат они у нас красиво в ~/.acme.sh и никак не используются. Надо каким-то образом их распространять на сервера. Далее расскажу, как я это делаю с помощью ansible. Ansible используется и для получения\обновления и для распространения. Сразу предупреждаю, мои плейбуки простые как три копейки и заточены под определенную инфраструктуру. Playbooks, hosts на github.

Мой сервер с ansible, уже имеет доступ ко всем необходимым серверам, на нём установлен acme.sh и реализовано два плейбука, на получение и распространение. Кстати, не забудьте закомментировать acme.sh в crontab, что бы не было лишних запросов и путаницы.

Playbook для получения сертификатов

В vars указывается только технический домен, эта переменная используется несколько раз. Токен от API вынесен в отдельный vars файл, что бы хранить его в зашифрованном виде в git. Task "Date and time" нужен для логирования, что бы понимать когда именно что-то пошло не так. Следующие два плейбука это простой shell, отличаются друг от друга количеством доменов в одном файле сертификата. Всем доменам, которым не нужно сочетать в себе обычный и wildcard домен, идут списком в loop.

Домены, которые должны подходить как для обычного, так и для wildcard идут по втором taks, тоже с помощью loop. Если вам нужно например wilcard вида *.*.itdog.info, то просто добавьте ещё один -d и ещё один subkey в item. Опция ignore_errors необходима, потому что exit code 0 будет только 6 раз за год при обновлении сертификата, в остальное время будут сообщения о том, что сертификат не нужно обновлять, для ansible это ошибка на которой он будет останавливаться.

Для чего плейбук на получение? Ведь в acme.sh и так уже всё настроено!

В одном плейбуке мы собираем всю нашу конфигурацию, доступы и все домены, которым необходим TLS, как минимум, это удобно - не надо копаться конфигах acme.sh. В случае изменения, например, токена, мы просто редактируем его в vars_files, а если нужно добавить ещё один домен\подомен, мы просто добавляем его в loop. Ну и в случае переноса сервера, не нужно переносить ~/.acme.sh, только плейбуки с vars_files взять из git.

Playbook для распространения сертификатов

Здесь нужно писать конечно под вашу инфраструктуру, поэтому повторюсь, показываю это для примера.

Три типа серверов из моей инфраструктуры:

• tls-hosts - Обычный nginx установленный как пакет из стандартного репозитория

• tls-hosts-docker - Веб проект с тем же nginx, но уже в docker

• tls-hosts-docker-rename - Сторонний продукт, в который надо подкладывать сертификат и ключ с определённым именем в определённую директорию (например Harbor, Zabbix)

Первый кейс самый простой, мы сами пишем конфигурацию nginx и можем куда угодно положить сертификаты и как угодно назвать их. При обновлении сертификата, требуется сделать nginx -s reload

Во втором случае всё плюс-минус так же, но уже нужно сделать docker exec project-nginx -s reolad, т.е. уже другой handler.

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

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

nginx.itdog.info tls_path=/etc/letsencrypt/*.itdog.info/ DOMAIN=*.itdog.info

Для случаев, когда доменов на сервере несколько, делается два хоста с разными именами и одинаковым ansible_host (Совет, как сделать лучше, приветствуется).

nginx.example.com-1 ansible_host=nginx.example.com tls_path=/etc/letsencrypt/*.example.com/ DOMAIN=example.comnginx.example.com-2 ansible_host=nginx.example.com tls_path=/etc/letsencrypt/*.example.org/ DOMAIN=example.org

Для каждого типа серверов создана своя группа в hosts. Для каждой группы свои немного отличающиеся друг от друга tasks. Для tls-hosts-docker так же добавлена переменная с именем контейнера nginx. А для tls-hosts-docker-rename добавлена переменная, в которой задаётся конечное имя сертификата и ключа.

docker-zabbix.itdog.info tls_path=/root/docker-zabbix/zbx_env/etc/ssl/nginx/ DOMAIN=*.itdog.info CONTAINER=docker-zabbix_zabbix-web-nginx-pgsql_1 cert_name=ssl.crt key_name=ssl.key

Для nginx нужен fullchain и domain.key - копируются только они. Если файлы различаются, происходит копирование и срабатывает handler nginx -s reload. Так же есть проверка, перед тем как зарелоудить nginx, что это файл. У меня один раз был случай, в самом начале пользования acme.sh, скрипт вместо файла с сертификатом создал директорию. Прямо как traefik 1.7 создаёт acme.json директорию, вместо файла. Поэтому я сделал простую проверку. В идеале нужно делать проверку, что сертификат валидный и не просроченный, но для этого требуется иметь на каждом хосте python-pyOpenSSL.

Crontab

23 3 * * * /usr/bin/ansible-playbook /etc/ansible/playbook-get-tls.yml -v >> /var/log/get-tls.log23 4 * * * /usr/bin/ansible-playbook /etc/ansible/playbook-copy-tls.yml -v >> /var/log/copy-tls.log

Можно без проблем вызывать их каждый день, let's encrypt будет вежливо говорить, что пока не нужно обновляться. А когда придёт срок, сертификаты будут обновлены.

Мониторинг сертификатов

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

Я использую zabbix и скрипт от @selivanov_pavel

Проверим с его помощью мой домен локально

koala@x220 ~/t/acme.sh-test> ./ssl_cert_check.sh expire itdog.info 44341

41 день сертификат на itdog.info будет актуален. Сертификат в let's encrypt обновляется за 30 дней до протухания. А значит, например, если ему осталось жить 10 дней, значит что-то пошло не так и надо идти смотреть.

Темплейт состоит из одного item и одного trigger. Теплейт есть так же на github

ssl_cert_check.sh["expire","{HOST.NAME}","{$TLS_PORT}"]

В item две переменных, первая HOST.NAME берёт имя хоста, предполагается что у нас хост назван по доменному имени. Переменная $TLS_PORT по дефолту 443, но если нужно проверять на нестандартном порту, то записываем значение порта в macros.

Триггер тоже супер простой

{Check tls expire:ssl_cert_check.sh["expire","{HOST.NAME}","{$TLS_PORT}"].last()}<=10

Если полученное значение меньше 10ти - аллерт. Таким образом, мы узнаем если у нас начнут протухать сертификаты и будет 10 дней на починку.

Нормально работает?

Да, acme.sh + DNS API + ansible у меня крутится два года. acme.sh + DNS Alias + ansible крутится пол года. Проблемы возникали только, когда при тестировании доменов забыл отключить crontab и он принёс staging сертификат на прод. Такая проблема решается проверкой на валидность.

Да, в идеале, ansible должен проверять перед копированием, что сертификат валидный и не просроченный. А система мониторинга проверять, помимо expire, валидность сертификатов.

Недавно со мной связался Эдуард Шишкин и попросил опубликовать интервью (что я с радостью и делаю) в формате вопрос-ответ.
С первым интервью (2010-го года) можно ознакомиться здесь.

Для начала напомни, пожалуйста, читателям, где и кем ты работаешь.

Я работаю в должности Principal Storage Architect в компании Huawei Technologies, German Research Center. В отделе виртуализации занимаюсь разными аспектами хранения данных. Моя деятельность не связана с конкретной операционной системой.

Коммитишь ли ты сейчас в основную ветку ядра?

Очень редко, и только если это требует мой работодатель. Последний раз года три назад я посылал патчи, позволяющие повысить пропускную способность для хранилищ, расшаренных на хостах по протоколу 9p (другое название этого дела - VirtFS). Здесь надо сделать одно важное замечание: хоть я и давно работаю рядом с Линукс, его фанатом я никогда не являлся, то есть, "дышу ровно", как впрочем и ко всему остальному. В частности, если я заметил какой-то изъян, то могу указать на него максимум один раз. А так, чтобы потом за кем-то ходить и уговаривать - такого не будет.

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

Я так и не увидел каких-либо сдвигов в лучшую сторону. Основная проблема сообщества - это подмена науки политтехнологиями, персональными отношениями, мнением большинства, популизмом, советами "внутренних голосов", гнилыми компромиссами, всем чем угодно кроме науки. Computer science, как ни крути, прежде всего точная наука. И если кто-то начинает провозглашать для 2x2 своё значение, отличное от 4, под флагом "Linux way", либо под каким другим, то кроме вреда это вряд ли что принесёт. Все беды прежде всего от некомпетентности и необразованности тех, кто принимает решения. Если руководитель некомпетентен, он не способен принять объективное адекватное решение. Если он к тому же и бескультурный, он не способен найти компетентного специалиста, который даст ему правильный совет. С большой вероятностью выбор падёт на мошенника, говорящего "с виду правильные вещи". Вокруг некомпетентных лидеров-одиночек всегда складывается коррумпированное окружение. Причём, история не знает исключений на этот счёт, и сообщество - ярчайшее тому подтверждение.

Как ты оцениваешь прогресс в разработке Btrfs? Эта ФС избавилась от детских болезней? Как ты её для себя позиционируешь как ФС для дома или и для корпоративного применения тоже?

Не избавилась. Всё то, о чём я упоминал 11 лет назад, актуально и поныне. Одна из проблем Btrfs, делающая последнюю непригодной для серьёзных нужд, - это проблема свободного места. Я уж не говорю о том, что пользователю предлагается бежать в магазин за новым диском в ситуациях, когда любая другая ФС показала бы ещё уйму свободного места на разделе. Невозможность завершить операцию над логическим томом по причине нехватки свободного места - это тоже не самое страшное. Хуже всего то, что непривилегированный пользователь почти всегда может за достаточно короткое время в обход любых дисковых квот лишить всех свободного места. Выглядит это так (проверено для ядра Linux 5.12). На свежеинсталлированной системе запускается скрипт, который в цикле создаёт в домашней директории файлы с определенными именами, записывает в них данные по определенным смещениям и затем удаляет эти файлы. Через минуту работы этого скрипта ничего необычного не происходит. Через пять минут порция занятого места на разделе слегка увеличивается. Через два-три часа она достигает 50% (при начальном значении 15%). А после пяти-шести часов работы скрипт валится с ошибкой "нет свободного места на разделе". После этого вы уже не в состоянии записать на ваш раздел даже 4К файл. Происходит интересная ситуация: вы ничего на раздел в итоге не записали, а всё свободное место (порядка 85%) куда-то улетучилось. Анализ раздела, подвергнутого такой атаке, покажет множество узлов дерева, содержащих всего один айтем (объект, снабженный ключом), размером несколько байт. То есть, контент, который ранее занимал 15% дискового пространства оказался равномерно "размазанным" на весь раздел так, что новый файл записать уже некуда, ибо его ключ больше всех существующих, а свободные блоки на разделе закончились. Причем это всё происходит уже на базовой конфигурации Btrfs (безо всяких снапшотов, сабвольюмов и пр.), и не имеет значения то, как вы решили хранить тела файлов в той ФС (как "фрагменты" в дереве, или же как экстенты неформатированных блоков) - конечный результат будет один и тот же.

Подвергнуть такой атаке остальные файловые системы из апстрима вам не удастся (что бы вам там ни говорили). Причину проблемы я уже давно объяснил: это полное извращение в Btrfs понятия B-дерева, что делает возможным его спонтанное или намеренное вырождение. В частности, при некоторых нагрузках ваша ФС в процессе эксплуатации будет непрерывно "разваливаться" и сама, без посторонней помощи. Понятно, что всевозможные "поджимающие" фоновые процессы спасут дело только на индивидуальных десктопах. На коллективных же серверах злоумышленник всегда будет в состоянии их "опередить". Системный администратор даже не сможет определить, кто именно над ним издевался. Быстрее всего исправить эту проблему в Btrfs можно лишь восстановив структуру регулярного B-дерева, т.е. заново перепроектировав дисковый формат и переписав существенную часть кода Btrfs. Это займёт 8-10 лет вместе с отладкой при условии что разработчики чётко следовали оригинальным статьям по соответствующим алгоритмам и структурам данным, а не играли в "испорченный телефон", как это принято (и поощряется) в "Linux way". Сюда ещё надо прибавить время, необходимое разработчикам на то, чтобы понять всё это. Вот тут уже сложнее. Во всяком случае, 10 лет на понимание им не хватило. Ну, а до этого можете не уповать на чудо. Оно не произойдёт в виде опции монтирования "про которую мы с вами не знали", или в виде патча, который приготовить "всего-то делов". Для каждого такого скоропалительного "исправления" я предъявлю новый сценарий вырождения. B-деревья - это одна из моих излюбленных тем, и должен сказать, что вольности в обращении с собой эти структуры не терпят!

Как я для себя позиционирую Btrfs? Как нечто, что именоваться файловой системой категорически не может, не говоря уже об использовании. Ибо по определению ФС - это подсистема ОС, ответственная за эффективное управление ресурсом "дисковое пространство", чего в случае c Btrfs мы не наблюдаем. Ну, представьте, что вы пришли в магазин купить часы, чтобы не опаздывать на работу, а там вместо часов вам впарили электрогриль с таймером на 30 минут максимум. Так вот - с Btrfs ситуация ещё хуже.

Просматривая листы рассылок, я часто сталкиваюсь с утверждением, что эффективно управлять дисковым пространством уже не актуально по причине дешевизны накопителей. Это полнейший бред. Без эффективного менеджера дискового пространства ОС станет уязвимой и непригодной к использованию. Вне зависимости от того, какой ёмкости диски стоят на вашей машине.

Хотелось бы попросить прокомментировать прекращение поддержки Btrfs в RHEL.

Тут особо нечего комментировать, всё предельно ясно. Она же была у них "technology preview". Вот, и не прошла это самое "preview". Не висеть же вечно этому ярлыку! А запустить ущербный by-design продукт с полной поддержкой они не могут. RHEL - это энтерпрайз, то есть прописанные товарно-денежные отношения. Red Hat не может издеваться над пользователями, как это происходит в листе рассылки Btrfs. Просто представьте ситуацию: клиент, заплативший свои кровные за диск и ещё вам за поддержку, хочет понять, куда делось его дисковое пространство, после того, как он ничего не записал. Что вы ему на это ответите? Далее. В число клиентов Red Hat входят известные крупные банки, биржи. Представьте, что будет, если они подвергнутся DoS-атакам, основанным на упомянутой уязвимости в Btrfs. Как вы думаете, кто за это ответит? Тем, кто собрался ткнуть пальцем в строчку лицензии GPL, где написано, что автор ни за что не отвечает, сразу скажу: "спрячьте её подальше!" Ответит Red Hat, причём так, что мало не покажется! Но я знаю, что Red Hat-у такого рода проблемы не грозят, учитывая их особенно сильную команду QA-инженеров, с которыми мне довелось плотно поработать в своё время.

Почему некоторые компании продолжают поддерживать Btrfs в своих энтерпрайз-продуктах?

Заметьте, что приставка "энтерпрайз" в названии продукта мало о чём говорит. Энтерпрайз - это мера ответственности, заложенная в договорные отношения с клиентом. Я знаю только один энтерпрайз, основанный на GNU/Linux - это RHEL. Всё остальное, с моей точки зрения, лишь выдаётся за энтерпрайз, но таковым не является. И, наконец, если на что-либо есть спрос, то всегда будет и предложение (в нашем случае это упомянутая "поддержка"). Спрос же бывает абсолютно на всё, в т.ч. и на непригодный к использованию софт. Как он формируется такой спрос, и кто его подпитывает - это уже другая тема.

Так что, я бы не стал делать какие-то выводы после того, как Facebook по слухам развернул Btrfs на своих серверах. Более того, адреса тех серверов я бы порекомендовал тщательно хранить в тайне по вышеупомянутым причинам.

Почему в последнее время очень много усилий приложено к вылизыванию кода XFS? Ведь изначально это сторонняя ФС, да и ext4 давно стабильна и имеет преемственность от предыдущих таких же стабильных версий. Какой интерес у Red Hat'а к XFS? Есть ли смысл активно разрабатывать две похожие по предназначению ФС ext4 и XFS?

Уже не помню, чем это мотивировалось. Вполне возможно, что инициатива шла от клиентов Red Hat. Я помню, что проводились исследования такого рода: на некоторых файловых системах из апстрима создавалось гигантское количество объектов на хай-енд накопителях нового поколения. По результатам XFS повела себя лучше ext4. Вот её и стали продвигать как наиболее перспективную. В любом случае, я бы не искал тут чего-то сенсационного. По мне, так сменили шило на мыло. Разрабатывать ext4 и XFS нет смысла. Как параллельно, так и любую из них на выбор. Из этого ничего хорошего не получится. Хотя, в природе часто встречаются ситуации, когда потенций для роста много, а объёма куда расти нет. В этом случае возникают разные причудливо-уродливые новообразования, на которые все показывают пальцем ("О, смотри, чего только в этой жизни не увидишь!").

Считаешь ли ты вопрос о layer violation исчерпанным (в негативном смысле) с появлением функций шифрования в ext4, F2FS (не говоря уже о RAID в Btrfs)?

Вообще, введение каких-либо уровней и принятие решения о их ненарушении - это обычно вопрос политики, и я не берусь тут что-либо комментировать. Объективные же аспекты нарушения уровней мало кому интересны, но мы можем рассмотреть некоторые из них на примере нарушения "сверху", а именно, реализацию в ФС функциональности, уже имеющейся на block layer. Такое "нарушение" оправдано всего лишь за редким исключением. Для каждого такого случая вы сначала должны доказать две вещи: что это действительно нужно, и что дизайну системы при этом не будет причинён ущерб. Скажем, зеркалирование, которое традиционно являлось занятием для block layer, имеет смысл реализовать на уровне файловой системы. По разным причинам. Например, на дисковых накопителях имеет место "тихая" порча данных (bit rot). Это когда устройство исправно работает, но данные блока неожиданно повреждаются под воздействием жесткого гамма-кванта, испущенного далёким квазаром и т.п. Хуже всего, если этим блоком оказался системный блок ФС (суперблок, bitmap-блок, узел дерева-хранилища и т.д), ибо это непременно приведёт к kernel panic. Заметьте, что зеркала, предлагаемые block layer (т.н. RAID 1) от этой проблемы не спасут. Ну, действительно: кто-то же должен проверять контрольные суммы и считывать реплику в случае неудачи? Кроме того, имеет смысл зеркалировать не тупо все подряд, а только метаданные. Некоторые важные данные (к примеру, исполняемые файлы критических приложений) можно хранить на правах мета-данных. В этом случае они получают такие же гарантии сохранности. Защиту же остальных данных имеет смысл поручить другим подсистемам (возможно, даже пользовательским приложениям) - мы предоставили для этого все необходимые условия. Такие "экономные" зеркала вполне имеют право на существование и эффективно их организовать можно только на уровне файловой системы. В остальном же layering violation - это захламление подсистемы дублированным кодом ради каких-то микроскопических выгод. Яркий тому пример - это реализация RAID-5 средствами ФС. Такие решения (собственные RAID / LVM в файловой системе) убивает последнюю в архитектурном плане. Здесь ещё нужно отметить, что layering violation "поставлено на поток" разного рода маркетинговыми мошенниками. За отсутствием каких-либо идей, в подсистемы добавляется функциональность давно уже реализованная на соседних уровнях, это выдается за новую черезвычайно полезную фичу и активно проталкивается.

Reiser4 же обвинили в нарушении уровней "снизу". Исходя из того, что файловая система не монолитная, как все остальные, а модульная, было сделано ничем не обоснованное предположение, что она занимается тем, чем должен заниматься уровень выше (VFS).

Можно ли говорить о смерти ReiserFS v3.6 и, например, JFS? Последнее время им в ядре почти не уделяется внимания. Они морально устарели?

Здесь надо определить, что значит смерть программного продукта. С одной стороны, они с успехом используются (их для этого и создавали, в конце концов) - значит живут. С другой стороны, не скажу за JFS (мало знаю), а вот ReiserFS (v3) очень трудно приспособить к новым тенденциям (проверено на практике). Значит, разработчики в дальнейшем будут уделять внимание не ей, а тем, которые легче приспособить. С этой стороны получается, что, увы, мертва в архитектурном плане. Понятием "морально устаревший" я бы вообще не манипулировал. Оно хорошо применимо, например, к гардеробу, но никак не к программным продуктам. Есть понятие уступать и превосходить в чем-либо. Совершенно точно могу сказать, что ReserFS v3 сейчас во всём уступает Reiser4, но на некоторых типах рабочей нагрузки превосходит все остальные ФС из апстрима.

Известно ли тебе о разработке ФС Tux3 и HAMMER/HAMMER2 (ФС для DragonFly BSD)?

Да, известно. В Tux3 меня когда-то заинтересовала технология их снимков (т.н. "версионные указатели"), но в Reiser4 мы, скорее всего, пойдём другим путём. Я давно думаю о поддержке снимков (snapshots) и ещё не определился с тем, как их реализовать для простых Reiser4 томов. Дело в том, что новомодная техника "ленивых" счётчиков ссылок, предложенная Охадом Родехом, работает лишь для B-деревьев. У нас их нет. Для тех структур данных, которые используются в Reiesr4, "ленивые" счётчики не определены - для их введения необходимо решить определённые алгоритмические проблемы, за что пока никто не брался.

По HAMMERу: читал статью от создателя. Не заинтересовало. Опять же, B-деревья. Эта структура данных безнадёжно устарела. Мы отказались от неё ещё в прошлом веке.

Как ты оцениваешь нарастающую востребованность в сетевых кластерных ФС по типу CephFS/GlusterFS/etc? Означает ли эта востребованность сдвиг приоритетов разработчиков в сторону сетевых ФС и недостаточность внимания к локальным ФС?

Да, такой сдвиг приоритетов произошел. Разработка локальных ФС стагнировала. Увы, сделать что-то существенное для локальных томов сейчас довольно сложно и далеко не всем под силу. Вкладываться в их разработку никто не хочет. Это примерно так же, как попросить коммерческую структуру выделить деньги на математические исследования - вас без этнузиазма спросят, а как на новой теореме можно будет заработать. Теперь локальная ФС - это нечто, что магически появляется "из коробки" и "всегда должно работать", а если не работает, то вызывает безадресное ворчание навроде: "да, что они там себе думают!". Отсюда недостаток внимания к локальным ФС, хотя работы в той области ещё невпроворот. И да, все повернулись к распределённым хранилищам, которые строятся на базе уже существующих локальных ФС. Это сейчас очень модно. Словосочетание "Big Data" у многих вызывает выброс адреналина, ассоциируясь с конференциями, воркшопами, большими зарплатами и т.п.

Насколько разумным в принципе выглядит подход, при котором сетевая ФС реализуется в пространстве ядра, а не в пространстве пользователя?

Очень разумный подход, который до сих пор нигде не был реализован. Вообще, вопрос о том, в каком пространстве надо реализовывать сетевую ФС - это "палка о двух концах". Ну, давайте рассмотрим на примере. Клиент записал данные на удалённой машине. Они упали в её page cache в виде грязных страниц. Это работа для "тонкого шлюза" сетевой ФС в пространстве ядра. Дальше операционная система рано или поздно попросит записать те страницы на диск для их освобождения. Тогда в дело включается IO-forwarding (отправляющий) модуть сетевой ФС. Он определяет на какую серверную машину (server node) эти страницы попадут. Потом эстафету принимает сетевой стек (а он, как мы знаем, реализован в пространстве ядра). Далее, server node принимает тот пакет с данными или метаданными и даёт указание backend storage - модулю (т.е. локальной ФС, которая работает в пространстве ядра) записать всё это хозяйство. Итак, мы свели вопрос к тому, где должны работать "отправляющий" и "принимающий" модули. Если какой-либо из тех модулей работают в пространстве пользователя, то это неминуемо приведёт к переключению контекстов (из-за необходимости пользования сервисами ядра). Число таких переключений зависит от деталей реализации. Если таких переключений много, то будет падать пропускная способность хранилища (производительность ввода-вывода). Если ваш backend storage составлен из медленных дисков, то значительного падения вы не заметите. Но если у вас диски быстрые (SSD, NVRAM и т.д), то переключение контекстов уже становится "бутылочным горлышком" и, сэкономив на переключении контекстов, производительность можно увеличить в разы. Стандартный путь такой экономии заключается в переносе модулей в пространство ядра. К примеру, мы выяснили, что перенос 9p-сервера из QEMU в ядро на хост-машине приводит к трёхкратному приросту производительности VirtFS. Это, конечно, не сетевая ФС, но суть вещей вполне отражает. Обратная сторона такой оптимизации - это проблемы с переносимостью. Для кого-то последняя может оказаться критичной. К примеру, GlusterFS вообще не имеет модулей в составе ядра. Благодаря этому она сейчас работает на многих платформах, в том числе и на NetBSD.

Какие концепции локальные ФС могли бы позаимствовать у сетевых и наоборот?

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

А вот локальным ФС есть чему поучиться у сетевых. Во-первых, у них стоит поучиться агрегировать логические тома на высоком уровне. Сейчас т.н. "передовые" локальные ФС агрегируют логические тома исключительно при помощи технологии "виртуальных девайсов", заимствованной из LVM (тот самый заразный layering violation, который сначала был реализован в ZFS). Иначе говоря, происходит трансляция виртуальных адресов (номеров блоков) в реальные и обратно на низком уровне (т.е. после того, как файловая система издала запрос ввода-вывода). Заметьте, что добавление и удаление устройств в логические тома (не зеркала), скомпанованные на block layer ведёт к проблемам, о которых поставщики подобных "фич" скромно умалчивают. Я говорю, о фрагментации на реальных устройствах, которая может достигать чудовищных значений, в то время, как на виртуальном устройстве у вас всё замечательно. Однако виртуальные устройства мало кого интересуют: всем интересно, что у вас происходит на реальных устройствах. Но ZFS-подобные ФС (также как и любые ФС в связках с LVM) работают только с виртуальными дисковыми устройствами (выделяют виртуальные дисковые адреса из числа свободных, дефрагментируют эти виртуальные устройства и т.д.). А что происходит на реальных устройствах они даже понятия не имеют! Теперь представьте, что на виртуальном устройстве у вас фрагментация равна нулю (то есть, у вас там живёт всего один гигантский экстент), вы добавляете диск в ваш логический том, а затем удаляете другой случайный диск из вашего логического тома с последующей перебалансировкой. И так вот много раз. Нетрудно сообразить, что на виртуальном устройстве у вас по-прежнему будет жить тот самый единственный экстент, но вот на реальных устройствах вы ничего хорошего уже не увидите. Хуже всего то, что вы даже не в состоянии исправить эту ситуацию! Единственное, что тут можно сделать - это попросить файловую систему дефрагментировать виртуальное устройство. Но она вам скажет, что у вас там всё замечательно - есть один только экстент, фрагментация равна нулю, а лучшего и быть не может! Итак, логические тома, скомпанованные на блочном уровне не предназначены для многократного добавления/удаления устройств. По-хорошему, нужно только один раз скомпановать логический том на блочном уровне, отдать его файловой системе, и потом ничего уже больше с ним не делать.

Кроме того, связка независимых подсистем ФС+LVM никак не позволяет учитывать разную природу накопителей, из которых агрегируются логические тома. Действительно, предположим, скомпановали вы логический том из НЖМД и твердотельных устройств. Но тогда первые потребуют дефрагментации, а вторые - нет. Для вторых нужно издавать discard-запросы, а для первых - нет, и т.п. Однако в указанной связке такую избирательность проявить достаточно сложно. Заметьте, что после создания в файловой системе своего собственного LVM, ситуация сильно лучше не становится. Более того, этим вы фактически ставите крест на перспективе когда-либо её улучшить в будущем. Это очень плохо. На одной и той же машине могут жить накопители разного типа. И если не файловая система будет их различать, то кто тогда?

Еще одна проблема подстерегает т.н. "Write-Anywhere" файловые системы (сюда же входит и Reiser4, если во время монтирования вы задали соответствующую транзакционную модель). Такие файловые системы должны предъявить беспрецедентные по своей мощи средства дефрагментации. А низкоуровневый менеджер томов тут не помогает, а только мешает. Дело в том, что с таким менеджером ваша ФС будет хранить карту свободных блоков только одного девайса - виртуального. Соответственно, дефрагментировать вы сможете только виртуальный девайс. Это значит, что дефрагментатор ваш будет долго-долго пахать на огромном едином пространстве виртуальных адресов. И если у вас много пользователей, делающих случайные перезаписи, то полезный эффект от такого дефрагментатора сведётся к нулю. Система ваша неминуемо начнёт тормозить, и вам останется лишь сложить руки перед неутешительным диагнозом "broken design". Несколько дефрагментаторов, работающих на одном и том же пространстве адресов будут только мешать друг другу. Совсем другое дело, если для каждого реального устройства вы поддерживаете свою карту свободных блоков. Это позволит эффективно распараллелить процесс дефрагментации. Но сделать это можно, лишь обладая высокоуровневым менеджером логических томов. Локальных ФС с такими менеджерами ранее не существовало (по крайней мере, я о них не знаю). Такими менеджерами обладали только сетевые ФС (например GlusterFS). Другой очень важный пример - утилита проверки целостности тома (fsck). Если для каждого подтома у вас хранится своя независимая карта свободных блоков, то процедуру проверки логического тома можно эффективно распараллелить. Иначе говоря, логические тома с высокоуровневыми менеджерами лучше масштабируются.

Кроме того, с низкоуровневыми менеджерами томов вы не сможете организовать полноценные снимки (snapshots). С LVM и в ZFS-подобных ФС вы можете делать только локальные снимки, но никак не глобальные. Локальные снимки позволяют моментально откатывать только регулярные файловые операции. A операции с логическими томами (добавление / удаление устройств) вам никто там не откатит. Давайте рассмотрим это на примере. В некоторый момент времени, когда у вас имеется логический том из двух устройств А и В, содержащий 100 файлов, вы делаете снимок S системы и затем создаете ещё одну сотню файлов. После этого вы добавляете к вашему тому устройство С, и наконец откатываете вашу систему к снимку S. Вопрос: сколько файлов и устройств содержит ваш логический том после отката к S? Файлов, как вы уже догадались, будет 100, но вот устройств будет 3 - это те же устройства A, B и C, хотя, на момент создания снимка в системе было всего два устройства (A и B). Операция добавления устройства C не откатилась, и если вы сейчас удалите устройство C из компьютера, то это закорраптит ваши данные, так что перед удалением вам вам нужно будет сначала провести дорогостоящую операцию удаления устройства из логического тома с перебалансировкой, которая раскидает все данные с устройства C на устройства A и B. А вот если бы ваша ФС поддерживала глобальные снимки, такая перебалансировка бы не потребовалась, и после моментального отката к S вы бы могли смело удалить устройство C из компьютера. Итак, глобальные снимки хороши тем, что они позволяют избежать дорогостоящего удаления (добавления) устройства из логического тома (в логический том) c большим количеством данных (разумеется, если вы не забыли "сфотографировать" свою систему в нужный момент). Напомню, что создание снимков и откат файловой системы к оным - моментальные операции. Может возникнуть вопрос: а как вообще такое возможно - моментально откатить операцию с логическим томом, которая заняла у вас три дня? А вот возможно! При условии, что ваша ФС правильно спроектирована. Идея таких "3D-снапшотов" у меня возникла три года назад, а в прошлом году я запатентовал эту методику.

Следующее, чему стоит поучиться локальным ФС у сетевых - это хранить метаданные на отдельных устройствах точно так же, как сетевые ФС хранят их на отдельных машинах (так называемые метадата-серверы). Есть приложения, работающие в основном с метаданными, и эти приложения можно значительно ускорить, разместив метаданные на дорогостоящих высокопроизводительных накопителях. Со связкой ФС+LVM проявить такую избирательность вам не удастся: LVM не знает, что там на блоке, который вы ему передали (данные там или же метаданные). От реализации в ФС собственного низкоуровневого LVM большого выигрыша по сравнению со связкой ФС+LVM вы не получите, а вот что у вас получится очень хорошо - так это захламить ФС так, что потом станет невозможно работать с её кодом. ZFS и Btrfs, поспешившие с виртуальными девайсами, - это всё наглядные примеры того, как layering violation убивает систему в архитектурном плане.Итак, к чему я всё это? Да к тому, что не нужно городить в файловой системе свой собственный низкоуровневый LVM. Вместо этого нужно агрегировать устройства в логические тома на высоком уровне, как это делают некоторые сетевые ФС с разными машинами (storage nodes). Правда, делают они это отвратительно по причине применения плохих алгоритмов. Примеры совершенно ужасных алгоритмов - это транслятор DHT в файловой системе GlusterFS и так называемый CRUSH map в файловой системе Ceph. Ни один из тех алгоритмов, что я видел, не устроил меня в плане простоты и хорошей масштабируемости. А потому пришлось вспоминать алгебру и изобретать всё самому. В 2015 году, экспериментируя с расслоениями над хэш-функциями, я придумал и запатентовал то, что меня устраивает. Сейчас могу сказать, что попытка реализовать всё это на практике оказалась успешной. Никаких проблем с масштабируемостью в новом подходе я не вижу. Да, каждый подтом потребует в памяти отдельную структуру типа суперблока. Это что, очень страшно? Вообще, я не знаю, кто собирается "кипятить океан" и создавать логические тома из сотен тысяч и более устройств на одной локальной машине. Если кто-нибудь мне это объяснит, буду очень благодарен. А пока что для меня это маркетинговый булшит.

Как повлияли изменения в подсистеме блочных устройств ядра (например, появление blk-mq) на требования к реализации ФС?

Никак не повлияли. Уж не знаю, что там должно такого случиться на block layer, что пришлось бы проектировать новую ФС. Интерфейс взаимодействия этих подсистем очень беден. Со стороны драйверов на ФС влиять должно только появление накопителей нового типа, к которым будет подстраиваться сначала block layer, а потом уже ФС (для reiser4 это будет означать появление новых плагинов).

Означает ли появление новых типов носителей (например, SMR, или повсеместное распространение SSD) принципиально новые вызовы для проектирования ФС?

Да. И это нормальные стимулы для развития ФС. Вызовы могут быть разные и совершенно неожиданные. К примеру, я слышал о накопителях, где скорость операции ввода-вывода сильно зависит от размера куска данных и его смещения. В Линуксе, где размер ФС-блока не может превышать размер страницы, такой накопитель по умолчанию не проявит свои полные возможности. Однако, если ваша ФС правильно спроектирована, то есть шанс много ещё чего из него "выжать".

Сколько людей сейчас работает с кодом Reiser4 кроме тебя?

Меньше, чем хотелось бы, но и острой нехватки ресурсов я не испытываю. Темпы развития Reiser4 меня более чем устраивают. "Гнать лошадей" я не собираюсь - это не та область. Здесь "тише едешь - дальше будешь!" Современная ФС - это самая сложная подсистема ядра, неправильные решения в дизайне которой могут перечеркнуть последующий многолетний труд людей. Предлагая волонтёрам что-то реализовать, я всегда гарантирую, что усилия непременно приведут к корректному результату, который может быть востребован для серьёзных нужд. Как вы понимаете, таких гарантий не может быть много и сразу. В то же время я терпеть не могу "деятелей", которые бесстыдно пиарят "фичи" заведомо непригодного для использования софта, обманывая сотни пользователей и разработчиков, да при этом сидят и улыбаются на кернел саммитах.

Выражала ли какая-нибудь компания готовность поддержать разработку Reiser4?

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

Каких функций не хватает в Reiser4 сейчас?

Не хватает функции "растяжения" (resize) для простых томов по аналогии с той, что имеется в ReiserFS(v3). Кроме того, не помешали бы файловые операции с флагом DIRECT_IO. Далее, хотелось бы уметь сегрегировать том на "семантические подтома", которые не имеют фиксированного размера, и которые можно монтировать как самостоятельные тома. Эти задачи хороши для начинающих, желающих попробовать себя в "настоящем деле". И, наконец, хотелось бы иметь сетевые логические тома с простой реализацией и администрированием (современные алгоритмы уже позволяют это сделать). А вот чего в Reiser4 точно никогда не будет - так это RAID-Z, скрабов, кэшей свободного пространства, 128-битных переменных и прочей маркетинговой ерунды, возникшей на фоне дефицита идей у разработчиков некоторых ФС.

Всё ли то, что может понадобиться, может быть реализовано плагинами?

Если говорить только в терминах интерфейсов и плагинов (модулей), которые их реализуют, то не всё. Но если ввести ещё и отношения на этих интерфейсах, то помимо всего прочего у вас возникнут понятия высших полиморфизмов, которыми уже можно обойтись. Представьте, что вы гипотетически заморозили объектно-ориентированную систему времени выполнения, поменяли значение instruction pointer, чтобы он указывал на другой плагин, который реализует тот же интерфейс X, а потом разморозили систему, так чтобы она продолжила выполнение. Если при этом конечный пользователь не заметит такой "подмены", то мы говорим, что система обладает полиморфизмом нулевого порядка в интерфейсе X (или система гетерогенна в интерфейсе X, что то же самое). Если теперь у вас не просто набор интерфейсов, а ещё имеются и отношения на них (граф интерфейсов), то можно ввести полиморфизмы и более высоких порядков, которые будут характеризовать гетерогенность системы уже в "окрестности" какого-либо интерфейса. Такую классификацию я когда-то давно ввёл, но опубликовать, к сожалению, так и не получилось. Так вот, при помощи плагинов и таких вот высших полиморфизмов можно описать любую известную фичу, а также "предсказать" те, которые никогда даже не упоминались. Строго доказать это мне не удалось, но и контрпримера я тоже пока не знаю. Вообще, вопрос этот напомнил мне "Эрлангенскую Программу" Феликса Клейна. Он в своё время пытался представить всю геометрию разделом алгебры (конкретно, теории групп).

Теперь к главному вопросу как обстоят дела с продвижением Reiser4 в основное ядро? Были ли публикации по архитектуре этой ФС, о которых ты говорил в прошлом интервью? Насколько вообще с твоей точки зрения этот вопрос актуален?

Вообще, мы в течение трёх лет просили о включении в основную ветку. Последний комментарий Рейзера в публичном треде, где был сделал запрос на включение так и остался без ответа. Так что все дальнейшие вопросы - не к нам. Я же лично не понимаю, зачем нам "вливаться" в конкретную операционную систему. На Линуксе свет клином не сошёлся. Так что, есть отдельный репозиторий, в котором будут несколько веток-портов под разные ОС. Кому нужно - можете клонировать соответствующий порт и делать с ним всё что заблагорассудится (в рамках лицензии, разумеется). Ну, а если это кому-то не нужно, то это не мои проблемы. На этом вопрос о "продвижении в основное ядро Линукс" я предлагаю считать исчерпанным.

Публикации по архитектуре ФС актуальны, но я пока что находил время только на свои новые результаты, которые считаю более приоритетными. Ещё дело в том, что я математик, а в математике любая публикация - это сводка теорем и их доказательств. Публиковать там что-либо без доказательства - это признак дурного тона. Если же я сторого докажу или опровергну какое-нибудь утверждение по архитектуре ФС, то получатся такие нагромождения, через которые будет довольно сложно продраться. Кому это нужно? Наверно, поэтому всё продолжает оставаться в своём старом виде - исходный код и комментарии к нему.

Что существенно нового появилось в Reiser4 за последние несколько лет?

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

Удалось, наконец, реализовать свою давнюю задумку - разные транзакционные модели. До этого в Reiser4 работала только одна жестковкодированная модель Макдональда-Рейзера. Это создавало проблемы в дизайне. В частности, в такой транзакционной модели невозможны снимки (snapshots) - их будет портить компонента атома под названием "OVERWRITE SET". Сейчас Reiser4 поддерживает три транзакционные модели. В одной из них (Write-Anywhere) в атомную компоненту OVERWRITE SET входят только системные страницы (образы дисковых битовых карт и т.п.), которые "фотографированию" не подлежат (проблема курицы и яйца). Так что снимки теперь можно реализовать в лучшем виде. В другой транзакционной модели все модифицированные страницы попадают только в OVERWRITE SET (то есть, это по сути чистое журналирование). Эта модель для тех, кто жаловался на быструю фрагментацию Reiser4 разделов. Теперь в этой модели ваш раздел будет фрагментироваться не быстрее чем с ReiserFS (v3). Все три существующие модели за некоторыми оговорками гарантируют атомарность операций, однако пригодиться могут также и модели с потерей атомарности и с сохранением лишь целостности раздела. Такие модели могут оказаться полезными для всевозможных приложений (базы данных и т.п.), которые уже взвалили на себя часть подобных функций. Добавить эти модели в Reiser4 очень легко, но я этого не делал, ибо меня никто не просил, а лично мне это не нужно.

Появились контрольные суммы метаданных и недавно я дополнил их "экономичными" зеркалами" (пока нестабильный материал). В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием "скраб" и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют "костылями".

И, наконец, появились гетерогенные логические тома, предлагающие всё то, чего ZFS, Btrfs, block layer, а также связки FS+LVM в принципе дать не могут - это параллельное масштабирование, O(1)-аллокатор дисковых адресов, прозрачная миграцией данных между подтомами. Для последней также имеется пользовательский интерфейс. Теперь наиболее "горячие" данные вы без труда можете переместить на самый высокопроизводительный накопитель вашего тома. Кроме того, имеется возможность экстренно сбрасывать на такой накопитель любые грязные страницы, и, тем самым, значительно ускорить приложения, часто вызывающие fsync(2). Отмечу, что функциональность block layer, называемая bcache, совершенно не предоставляет такой свободы действий. Новые логические тома основаны на моих алгоритмах (есть соостветствующие патенты). Софт уже достаточно стабилен, вполне можно попробовать, замерить производительность и т.п. Единственное неудобство - пока нужно вручную обновлять конфигурацию тома и где-то ёё хранить.

Реализовать свои задумки мне удалось пока что процентов на 10. Однако, удалось то, что я считал наиболее трудным - это "подружить" логические тома с флаш-процедурой, которая выполняет все отложенные действия в reiser4. Это всё пока в экспериментальной ветке "format41".

Проходит ли Reiser4 тесты xfstests?

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

Возможно ли в принципе с помощью плагинов сделать Reiser4 сетевой (кластерной) ФС?

Можно, и даже нужно! Если на основе правильно спроектированной локальной ФС создать сетевую, то результат будет очень впечатляющим! В современных сетевых ФС меня не устраивает наличие уровня backend storage, который реализуется при помощи любой локальной ФС. Существование этого уровеня совершенно неоправдано. Сетевая ФС должна нарямую взаимодействовать с block layer, и не просить локальную ФС создать ещё какие-то там служебные файлы! Вообще, деление файловых систем на локальные и сетевые - это от лукавого. Оно возникло от несовершенства алгоритмов, которыми пользовались тридцать лет назад, и вместо которых до сих пор ничего не было предложено. Это же является причиной появления массы ненужных софтверных компонет (различных сервисов и т.д). По-хорошему, должна быть только одна ФС в виде модуля ядра и набора пользовательских утилит, инсталлируемых на каждой машине - узле кластера. Эта ФС одновременно и локальная и сетевая. И ничего лишнего!

Если с Reiser4 в Linux'е так ничего и не получится, хотелось бы предложить ФС для FreeBSD (цитата из прошлого интервью: FreeBSD имеет академические корни А это означает, что с большой долей вероятности мы найдём с разработчиками общий язык)?

Итак, как мы только что выяснили, с Линуксом у нас всё уже прекрасно получилось: под него есть отдельный работающий порт Reiser4 в виде мастер-бранча нашего репозитория. Про FreeBSD я и не забыл! Предлагайте! Готов плотно поработать c теми, кто хорошо знает внутренности FreeBSD. Кстати: что мне очень нравится в их сообществе - там решения принимаются обновляемым советом независимых экспертов, не имеющим ничего общего с губонадувательством одной бессменной персоны.

Как ты оцениваешь сообщество пользователей Linux сегодня? Стало ли оно более попсовым?

Мне по роду своей деятельности оценить такое достаточно трудно. Ко мне в основном приходят пользователи с багрепортами и просьбами починить раздел. Пользователи как пользователи. Кто-то подкован больше, кто-то меньше. Ко всем отношение одинаковое. Ну, а если пользователь игнорирует мои указания, то тут уж извините: игнор будет введён и с моей стороны.

Возможно ли спрогнозировать развитие файловых систем на ближайшие пять-десять лет? Какие, по-твоему, основные вызовы могут стоять перед разработчиками ФС?

Да, сделать такой прогноз несложно. В апстриме давно уже нет никакого развития файловых систем. Создаётся лишь видимость такового. Разработчики локальных ФС упёрлись в проблемы связанные с неудачным дизайном. Здесь нужно сделать оговорку. Т.н "хранение", "вылизывание" и портирование кода я за развитие и разработку не считаю. А недоразумение под названием "Btrfs" к разработкам не причисляю по причинам, которые я уже объяснил. Каждый патч лишь усугубляет её проблемы. Ну. и всегда находятся разного рода "евангелисты", у которых "всё работает". В основном, это школьники и студенты, прогуливающие лекции. Вы только представьте: у него работает, а у профессора нет. Это какой же выброс адреналина! Наибольший же вред с моей точки зрения приносят "умельцы", бросившиеся с энтузиазмом "привинчивать" чудо-фичи Btrfs к всевозможным прослойкам типа systemd, docker, и т.п. - это уже напоминает метастазы.

Давайте теперь попробуем сделать прогноз на пять-десять лет. Что мы будем делать в Reiser4 я вкратце уже перечислил. Основным вызовом для разработчиков локальных ФС из апстрима станет (да, уже стало) невозможность заниматься приличным делом за зарплату. Без каких-либо идей в области хранения данных они будут продолжать пытаться патчить эти несчастные VFS, XFS и ext4. Особенно комично на этом фоне выглядит ситуация с VFS, напоминающая остервенелую модернизацию ресторана в котором поваров нет, и не предвидится. Теперь код VFS безо всяких условий залочивает одновременно несколько страниц памяти и предлагает нижележащей ФС оперировать над ними. Это было введено для повышения производительности Ext4 на операциях удаления, но, как нетрудно понять, такой одновременный лок совершенно несовместим с продвинутыми транзакционными моделями. То есть, добавить поддержку какой-то умной ФС в ядре вы уже просто так не сможете. Я не знаю, как дело обстоит в остальных областях Linux, но что касается файловых систем, какое-либо развитие здесь вряд ли совместимо с политикой, проводимой Торвальдсом на деле (академические проекты изгоняются, а мошенникам, не имеющим понятия, что такое B-дерево, выдаются бесконечные кредиты доверия). Поэтому тут был взят курс на медленное загнивание. Его, конечно же, изо всех сил будут пытаться выдать за "развитие". Далее, "хранители" файловых систем, поняв, что на одном лишь "хранении" много не заработаешь, будут пробовать себя в более прибыльном бизнесе. Это, как правило, распределенные файловые системы и виртуализация. Возможно, куда-то ещё будут портировать модную ZFS там, где её ещё нет. Но она, как и все ФС из апстрима, напоминает новогоднюю ёлку: если сверху ещё что-то из мелочи повесить можно, то глубже уже не подлезешь. Я допускаю, что построить серьёзную энтерпрайз-систему на базе ZFS можно, но поскольку мы сейчас обсуждаем будущее, то мне остаётся с сожалением констатировать, что ZFS в этом плане безнадёжна: своими виртуальными девайсами ребята перекрыли себе и будущим поколениям кислород для дальнейших разработок. ZFS - это вчерашний день. А ext4 и XFS - уже даже не позавчерашний.

Отдельно стоит сказать про нашумевшее понятие "Linux file system of next generation". Это полностью политический и маркетинговый проект, созданный для возможности, так скажем, "столбить будущее файловых систем" в Linux за конкретными персонажами. Дело в том, что это раньше Linux был "just for fun". А сейчас это прежде всего машина для зарабатывания денег. Они делаются на всём, на чём только можно. К примеру, создать хороший программный продукт очень трудно, но смышленые "разработчики" давно уже сообразили, что напрягаться-то вовсе и не нужно: успешно продавать можно и несуществующий софт, анонсированный и распиаренный на всевозможных публичных мероприятиях - главное, чтобы в презентационных слайдах было побольше "фич". Файловые системы подходят для этого как нельзя лучше, ибо на результат можно смело выторговывать лет десять. Ну, а если кто-то потом будет сетовать на отсутствие этого самого результата, то он же в файловых системах просто ничего не смыслит! Это напоминает финансовую пирамиду: на вершине располагаются заварившие эту кашу авантюристы, и те немногие, кому "повезло": они "сняли дивиденды", т.е. получили деньги на разработку, устроились менеджерами на высокооплачиваемую работу, "засветились" на конференциях, и т.п. Далее идут те, кому "не повезло": они будут подсчитывать убытки, расхлебывать последствия развертывания в продакшн непригодного программного продукта ", и т.д. Их гораздо больше. Ну, и в основании пирамиды - огромная масса разработчиков, "пилящих" никчёмный код. Они - в самом большом проигрыше, ибо впустую потраченное время не вернёшь. Такие пирамиды чрезвычайно выгодны Торвальдсу и его приближенным. И чем этих пирамид больше - тем для них лучше. Для подпитки таких пирамид в ядро может быть принято всё что угодно. Разумеется, на публике они утверждают обратное. Но я сужу не по словам а по поступкам.

Так что, "будущее файловых систем в Линукс" - это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого "будущего" займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть! Авторы Bcachefs и Btrfs, создавая свои ФС, активно пользовались чужими исходниками, мало что в них понимая. Ситуация очень напоминает детскую игру "испорченный телефон". И я примерно представляю, как будет происходить включение этого кода в ядро. Собственно "грабли" никто не увидит (на них все будут наступать потом). После многочисленных придирок к стилю кода кода, обвинению в несуществующих нарушениях, и пр. будет делаться заключение о "лояльности" автора, о том, насколько он хорошо "взаимодействует" с остальными разработчиками, и как успешно всё это потом можно будет продавать корпорациям. Конечный же результат никого не заинтересует. Лет двадцать назад, может быть, бы и заинтересовал, но сейчас вопросы ставятся по-другому: получится ли это раскрутить так, чтобы ближайший десяток лет определённые люди оказались трудоустроены. А задаваться вопросом о конечном результате, увы, не принято.

А вообще, я бы настоятельно не рекомендовал начинать изобретать свою файловую систему "с нуля". Ибо даже существенных финансовых вложений будет недостаточно, чтобы лет за десять получить что-то конкурентоспособное. Разумеется, я говорю о серьёзных проектах, а не о тех, которые предназначены для "проталкивания" в ядро. Так что, более эффективный способ заявить о себе - это присоединиться к реальным разработкам, например к нам. Сделать это, разумеется, непросто - но так дело обстоит с любым проектом высокого уровня. Сначала нужно будет самостоятельно одолеть задачку, которую я предложу. После чего, убежденный в серьёзности ваших намерений, я начну помогать. Традиционно мы используем только собственные наработки. Исключение составляют алгоритмы компрессии и некоторые хэш-функции. Мы не отправляем разработчиков колесить по конференциям, а потом не сидим и не комбинируем чужие идеи ("авось, чего и получится"), как это принято в большинстве стартапов. Все алгоритмы мы разрабатываем сами. В настоящий момент меня интересуют алгебраические и комбинаторные аспекты науки хранения данных. В частности, конечные поля, асимптотика, доказательство неравенств. Для простых программистов тоже найдётся работа, однако должен сразу предупредить: все предложения "посмотреть на другую ФС и сделать так же" отправляются в игнор. Туда же пойдут патчи, направленные на более тесную интеграцию с Linux по линии VFS. Итак, у нас нет граблей, а есть понимание, куда надо двигаться, и есть уверенность, что это направление правильное. Такое понимание не пришло в виде манны небесной. Я напомню, что позади 29-летний опыт разработок, две файловые системы написанные "с нуля". И столько же утилит восстановления данных. А это очень много!

• https://sourceforge.net/projects/reiser4/files/

• https://github.com/edward6/reiser4

7го июня компания Apple провела свою ежегодную конференцию для разработчиков - WWDC (Worldwide Developers Conference), на которой, помимо всего, была представлена новая версия macOS - Monterey. Спустя некоторое время стала доступна бета-версия, про которую, сегодня, и пойдет речь.

Внимание! Мы ни коем образом не рекомендуем Вам устанавливать и использовать как основные бета версии операционных систем. В случае, если Вы таки решились на установку, Вы делаете это на свой страх и риск! Автор статьи не несёт никакой ответственности за возможные последствия.

Какие модели Mac поддерживаются macOS Monterey?

Полный список поддерживаемых моделей, опубликованный Apple на своём же сайте

• iMac конца 2015 года или новее

• iMac Pro 2017 года или новее

• MacBook Air начала 2015 года или новее

• MacBook Pro начала 2015 года или новее

• Mac Pro конца 2013 года или новее

• Mac mini конца 2014 года или новее

• MacBook (12 дюймов) начала 2016 года или новее

Нововведения

Тут стоило бы начать с того, что большинство представленных на WWDC функций не будут работать на Mac с процессорами Intel. Скорее всего, это связано с тем, что в Mac на Intel отсутствует чип Neural Engine, выполняющий вычисления для машинного обучения. А вот в чём Apple реально огорчили, так это тем, что об этом банально не сказали на конференции.

Вот список всех нововведений, отсутствующих на Mac с Intel:

• Функция Live Text, позволяющая взаимодействовать с текстом на фото.

• Функция "Portait Mode" для FaceTime.

• Text-to-speech для финского, датского, норвежского, шведского языка.

• Interactive Glove в приложении Карты.

• Непрерывная диктовка с клавиатуры.

• "Прокачанные" карты Лондона, Сан-Франциско, Нью Йорка и Лос-Анджелеса.

Полный список нововведений можете прочитать тут (напомню, некоторые функции не работают на процессорах Intel)

Когда ждать релиз macOS Monterey?

Точная дата выхода релизной версии новой ОС неизвестна. Известно лишь то, что это будет осенью этого года.

В заключение

Безусловно, macOS Monterey уже имеет много полезных функций (чего стоит один Universal Control). Не исключено, что с новыми бета-версиями их количество может пополниться. Правда некоторые из них, как было описано выше, не работают на процессорах Intel, и вряд-ли когда-нибудь будут на них работать, Apple же нужно как-то продавать "маки" на M1, верно.

Пишите в комментах, что вы думаете о новой ОС от Apple. Также какие нововведения лично вы ожидали увидеть, но их так и не показали.

До скорого!

7го июня компания Apple провела свою ежегодную конференцию для разработчиков - WWDC (Worldwide Developers Conference), на которой, помимо всего, была представлена новая версия macOS - Monterey. Спустя некоторое время стала доступна бета-версия, про которую, сегодня, и пойдет речь.

Внимание! Мы ни коем образом не рекомендуем Вам устанавливать и использовать как основные бета версии операционных систем. В случае, если Вы таки решились на установку, Вы делаете это на свой страх и риск! Автор статьи не несёт никакой ответственности за возможные последствия.

Какие модели Mac поддерживаются macOS Monterey?

Полный список поддерживаемых моделей, опубликованный Apple на своём же сайте

• iMac конца 2015 года или новее

• iMac Pro 2017 года или новее

• MacBook Air начала 2015 года или новее

• MacBook Pro начала 2015 года или новее

• Mac Pro конца 2013 года или новее

• Mac mini конца 2014 года или новее

• MacBook (12 дюймов) начала 2016 года или новее

Нововведения

Тут стоило бы начать с того, что большинство представленных на WWDC функций не будут работать на Mac с процессорами Intel. Скорее всего, это связано с тем, что в Mac на Intel отсутствует чип Neural Engine, выполняющий вычисления для машинного обучения. А вот в чём Apple реально огорчили, так это тем, что об этом банально не сказали на конференции.

Вот список всех нововведений, отсутствующих на Mac с Intel:

• Функция Live Text, позволяющая взаимодействовать с текстом на фото.

• Функция "Portait Mode" для FaceTime.

• Text-to-speech для финского, датского, норвежского, шведского языка.

• Interactive Glove в приложении Карты.

• Непрерывная диктовка с клавиатуры.

• "Прокачанные" карты Лондона, Сан-Франциско, Нью Йорка и Лос-Анджелеса.

Полный список нововведений можете прочитать тут (напомню, некоторые функции не работают на процессорах Intel)

Когда ждать релиз macOS Monterey?

Точная дата выхода релизной версии новой ОС неизвестна. Известно лишь то, что это будет осенью этого года.

В заключение

Безусловно, macOS Monterey уже имеет много полезных функций (чего стоит один Universal Control). Не исключено, что с новыми бета-версиями их количество может пополниться. Правда некоторые из них, как было описано выше, не работают на процессорах Intel, и вряд-ли когда-нибудь будут на них работать, Apple же нужно как-то продавать "маки" на M1, верно.

Пишите в комментах, что вы думаете о новой ОС от Apple. Также какие нововведения лично вы ожидали увидеть, но их так и не показали.

До скорого!

Мало того, что многие не доверяют общедоступным облакам, так они еще и предлагают непозволительно малые объемы дискового пространства.

Однажды мне понадобилось 1Tb облачного хранилища и выбор пал на Nextcloud, который и было решено развернуть на собственном домашнем сервере

В данной статье я опишу как быстро и безболезненно установить и настроить облако Nextcloud и облачный редактор Onlyoffice

Статья предполагает, что у вас уже установлен и настроен Ubuntu.

Все действия были проверены на Ubuntu Server 20.04

Что будем делать:
1. Установим Nginx, PHP и MariaDB
2. Добавим бесплатный SSL-сертификат Let's Encrypt
3. Развернем NextCloud
4. Произведем тонкие настройки сервера
5. Установим Onlyoffice

Бесплатные доменные имена в домене .tk можно получить на www.freenom.com

Первым делом, устанавливаем вспомогательные утилиты

sudo apt-get install nano mc zip -y

Этот пункт можно пропустить, если настраиваете облако на локальный диск, а не на отдельную машину с доступом по nfs, мне понадобилось сделать это именно на nfs

# Ставим nfs-clientsudo apt install nfs-common -y# -------------------# Монтируем папку nfs# Ставим nginxsudo mkdir -p /nfs/ncsudo mount your_host_ip:/папка_шары_nfs/ /nfs/ncsudo ls -l /nfs/nc/sudo df -hsudo du -sh /nfs/nc/# -------------------# Монтируем nfs при загрузкеsudo nano /etc/fstab# Добавим такую строку в конец файлаyour_host_ip:/папка_шары_nfs/  /nfs/nc  nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Ставим nginx

sudo apt install nginx -ysudo nginx -Vsudo systemctl enable nginxsudo systemctl start nginx

Ставим php 7.4

sudo apt install php7.4-fpm php7.4-mysql php7.4 php7.4-curl php7.4-gd php7.4-json php7.4-mbstring php7.4-common php7.4-xml php7.4-zip php7.4-opcache php-apcu php-imagick -y

Настраиваем php 7.4

sudo nano /etc/php/7.4/fpm/pool.d/www.conf

снимаем комментарии со строк

env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

# Настраиваем php.ini:

sudo nano /etc/php/7.4/fpm/php.ini

opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Разрешаем автозапуск php-fpm и перезапускаем его:

sudo systemctl enable php7.4-fpmsudo systemctl restart php7.4-fpm

Устанавливаем MariaDB:

sudo apt install mariadb-serversudo systemctl enable mariadbsudo systemctl start mariadb

Запуск сценария безопасности (здесь можно поменять пароль рута, убрать ненужные разрешения):

sudo mysql_secure_installation

Создаем базу данных для Nextcloud (в примере указан пароль nextcloud, его лучше заменить на свой) :

sudo mysql -u root -p

Вводим пароль рута для MariaDB

 >CREATE DATABASE nextcloud;CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud';GRANT ALL ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud' WITH GRANT OPTION;FLUSH PRIVILEGES;EXIT;

Теперь надо создать файл конфигурации Nginx для Nextcloud

sudo nano /etc/nginx/sites-enable/nextcloud.conf

И вставляем в него следующий текст, естественно, заменив nc.myhost.com на свои сервера

server {    listen 80;    server_name nc.myhost.com;    return 301 https://$server_name$request_uri;}server {    listen 443 ssl;    server_name nc.myhost.com;    ssl_certificate /etc/nginx/ssl/cert.pem;    ssl_certificate_key /etc/nginx/ssl/cert.key;    root /var/www/nextcloud;    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;    client_max_body_size 10G;    fastcgi_buffers 64 4K;    rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;    rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;    rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;    index index.php;    error_page 403 = /core/templates/403.php;    error_page 404 = /core/templates/404.php;    location = /robots.txt {      allow all;      log_not_found off;      access_log off;    }    location ~ ^/(data|config|\.ht|db_structure\.xml|README) {        deny all;    }    location / {        rewrite ^/.well-known/host-meta /public.php?service=host-meta last;        rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;        rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;        rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;        rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;        try_files $uri $uri/ index.php;    }    location ~ ^(.+?\.php)(/.*)?$ {        try_files $1 = 404;        include fastcgi_params;        fastcgi_param SCRIPT_FILENAME $document_root$1;        fastcgi_param PATH_INFO $2;        fastcgi_param HTTPS on;        fastcgi_pass unix:/run/php/php7.4-fpm.sock;    }    location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {        expires modified +30d;        access_log off;    }}

Теперь необходимо получить сертификаты для ssl

Устанавливаем Certbot и его плагин для Nginx:

sudo apt install certbot python3-certbot-nginx

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

Сначала с ключом --dry-run проверяем все ли в порядке

sudo certbot certonly --agree-tos --email you@mail -d nc.myhost.com-d www.myhost.com -d zabbix.myhost.com --nginx --dry-run --d

Если все хорошо, то получаем сертификаты

sudo certbot certonly --agree-tos --email почта@администратора -d myhost.com-d nc.myhost.com-d cloud.myhost.com-d zabbix.myhost.com-d www.myhost.com-d mail.myhost.com sudo certbot certonly --agree-tos --email your@mail -d nc.myhost.com-d www.33rus.com -d zabbix.33rus.com --nginx n 

Сертификаты появятся в папке /etc/letsencrypt/live/myhost.com cert.pem chain.pem fullchain.pem privkey.pem

Подключаем сертификаты к сайту

sudo nano /etc/nginx/sites-available/nextcloud.conf

ssl_certificate /etc/letsencrypt/live/myhost.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/myhost.com/privkey.pem;

Устанавливаем Nextcloud:

Скачиваем последнюю версию с сайте Nextcloud:

cd /tmp/sudo wget https://download.nextcloud.com/server/releases/nextcloud-21.0.0.zipsudo unzip nextcloud-21.0.0.zipsudo cp -R nextcloud /var/www/nextcloud/cd /var/www/sudo chown -R www-data:www-data nextcloud/sudo chown -R www-data:www-data /nfs/nc

Обратите внимание, в данном случае я использую папку на nfs, вам необходимо использовать папку в соответствии с вашими настройками

Почти все. Заходим на https://nc.myhost.com
Создаем пользователя, пароль, прописываем доступ к каталогу /nfs/nc/
Прописываем созданную ранее базу данных и пароль к ней.

Теперь тонкая настройка Nextcloud и установка Onlyoffice

Ставим Redis и APCu

sudo apt install memcached php-memcached -ysudo apt install php-apcu redis-server php-redis -ysudo nano /var/www/nextcloud/config/config.php

И добавляем следующие строки перед закрывающей скобкой )

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 6379,
),
'memcache.locking' => '\OC\Memcache\Redis',

Переиндексация файлов (если вдруг вы скопировали файлы в папку nexcloud не через интерфейсы nextcloud, то их надо переиндексировать)

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Устанавливаем OnlyOffice DocumentServer

Первым делом устанавливаем версию PostgreSQL, включенную в вашу версию Ubuntu:

sudo apt install postgresql -y

После установки PostgreSQL создайте базу данных и пользователя PostgreSQL:

Пользователем и паролем для созданной базы данных должны быть onlyoffice.

sudo -i -u postgres psql -c "CREATE DATABASE onlyoffice;"sudo -i -u postgres psql -c "CREATE USER onlyoffice WITH password 'onlyoffice';"sudo -i -u postgres psql -c "GRANT ALL privileges ON DATABASE onlyoffice TO onlyoffice;"

Установка rabbitmq и nginx-extras:

sudo apt install rabbitmq-server -ysudo apt install nginx-extras -y

Установка ONLYOFFICE Docs

Добавьте GPG-ключ:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys CB2DE8E5

Добавьте репозиторий ONLYOFFICE Docs:

sudo echo "deb https://download.onlyoffice.com/repo/debian squeeze main" | sudo tee /etc/apt/sources.list.d/onlyoffice.list sudo apt update

Устанавливаем mariadb-client!

sudo apt install mariadb-client -y

Устанавливаем ONLYOFFICE Docs. Не ошибитесь с вводом пароля. Это должен быть onlyoffice

sudo apt install onlyoffice-documentserver -y

Переводим onlyoffice на https

sudo cp -f /etc/onlyoffice/documentserver/nginx/ds-ssl.conf.tmpl /etc/onlyoffice/documentserver/nginx/ds.confsudo nano /etc/onlyoffice/documentserver/nginx/ds.conf 

Меняем порт ssl не забыв пробросить его в роутере

listen 0.0.0.0:7443 ssl;
listen [::]:7443 ssl default_server;

Перезапускаем nginx

sudo service nginx restart

Настраиваем cron

sudo crontab -u www-data -e

# Добавляем строчку

*/5 * * * * php -f /var/www/nextcloud/cron.php

Ну, вот и все, останется через веб-интерфейс установить плагин ONLYOFFICE в вашем Nextcloud и прописать сервер https://myhost.com:7443