Русский
Русский
English
Статистика
Реклама

Linux

Перевод Floppinux Linux, умещенный на дискету

26.05.2021 12:10:08 | Автор: admin

Новость по этому поводу уже была, время подавать и сам перевод. В своем руководстве Кристиан подробно излагает каждый шаг процесса создания дистрибутива и его записи на дискету формата 3.5". В конечном итоге работает такой дистрибутив даже не старых ПК с i486DX и вполне может выполнять скомпилированные приложения.

Уже более 7 лет я использую Linux в качестве основной ОС. С этой системой я экспериментирую с момента появления Fedora и Ubuntu и все еще помню получение бесплатных Live-CD от Canonical. Сейчас Linux уже установлена на всех моих компьютерах, включая Raspberry Pi и смартфоны.
Я даже администрирую два сервера IBM, которые также работают на Linux. Но при всем при этом мне до сих пор еще многое неизвестно о его внутреннем устройстве. В итоге я решил обогатить свои знания, реализовав забавный и в то же время полезный мини-проект.

Введение


Я с нуля создал встраиваемый дистрибутив Linux, уместив его всего на одну дискету. На момент написания он занимает около 1Мб, так что остается еще примерно 400Кб для дополнительного ПО.

Этот дистрибутив может загружаться на 486DX с 24 Мб ОЗУ (при меньшем объеме с помощью QEMU не загрузился). Через эмулятор загрузка происходит практически мгновенно. Что же касается современного железа, не обремененного программной нагрузкой, то единственное, что ограничивает скорость загрузки это скорость самого дисковода. Ее максимальный показатель составляет 125Кб/с, но в реальности даже меньше.

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


FLOPPINUX, запущенный на Asus Eee PC 701SD Intel Celeron-M 900МГц с 512Мб ОЗУ

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

Если у вас есть желание проделать нечто подобное, то эта статья для вас.

Выбор приложения


Первым приложением, которое я хочу запустить, будет создаваемый мной олдскульный журнал Nomad Diskmag, который я планирую выпускать на дискетах. Для ПК я разработал приятный GUI с помощью PyGame. Что касается моего встраиваемого проекта, то для него я заменю фронтенд на скрипт bash. Статьи в обеих версиях представляют простые файлы .txt, поэтому все что нужно это создать обложку, содержание и выполнить cat для вывода тела каждого файла (используя less для вывода страниц).

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

Цели проекта



Красочные прозрачные дискеты!

Очевидная и наиболее важная цель уместить все (ОС + ПО) на одну дискету или в 1440 Кб. В остальном же их можно описать так:

  • Последнее ядро Linux.
  • Минимум инструментов, необходимых для поддержки встраиваемого приложения.
  • Документация с легкими и понятными шагами для воспроизведения сборки.
  • Ну и, как обычно, открытый исходный код.

Будущие дополнения:

  • Возможность монтировать другую дискету для сохранения файлов.
  • Текстовый редактор nano (или подобный).

Сборка дистрибутива FLOPPINUX



Gold Master Floppy для FLOPPINUX VERSION 0.1.0

x86_64 и x86


Компилировать 32-битный код на 64-битной системе не очень удобно, и чтобы упростить процесс, я просто проделываю это на старом ноутбуке с 32-битным ЦПУ.

Также можно использовать VirtualBox с 32-битной системой.

Если же вы хотите использовать 64-битную хост-систему, добавляйте к командам ARCH=x86. Вот пример:

make ARCH=x86 tinyconfig

EPUB


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

Ссылка для скачивания: https://archive.org/details/floppinux-manual/

Рабочая директория


Создайте директорию, где будете хранить все файлы.

mkdir ~/my-linux-distro/cd ~/my-linux-distro/

Ядро


Я использую последнюю версию, которая объединяет в себе старые и новые технологии. На данный момент это Kernel 5.13.0-rc2.

Получение ресурсов:

git clone --depth=1 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.gitcd linux

Теперь, когда они находятся у вас в каталоге /linux/, перейдем к настройке и сборке собственного ядра. Начнем с создания минимальной конфигурации:

make tinyconfig

Теперь нужно добавить поверх нее дополнительные настройки:

make menuconfig

Из меню выберите следующие опции:

  • Processor type and features > Processor family > 486
  • Device Drivers > Character devices > Enable TTY
  • General Setup > Configure standard kernel features (expert users) > Enable support for printk
  • General Setup > Initial RAM filesystem and RAM disk (initramfs/initrd)
  • Executable file formats > Kernel support for ELF binaries
  • Executable file formats > Kernel support for scripts starting with #!

Далее выходим из конфигурации с сохранением настроек в .config. А теперь компиляция:

make bzImage

Скорость процесса будет зависеть от скорости вашего ЦПУ. В конечном итоге ядро будет создано в arch/x86/boot/bzImage. Переместите его в основную директорию.

mv arch/x86/boot/bzImage ../

Инструменты


Без инструментов ядро будет просто загружаться, и вы ничего не сможете делать. Одной из самых популярных и легковесных утилит является BusyBox. Она заменяет (более объемные) инструменты GNU функциональностью, которой достаточно для процессов встраивания.

Последнюю версию этого продукта можно найти в соответствующем разделе их сайта https://busybox.net/downloads/. На данный момент это 1.33.1. Скачайте файл, извлеките его и смените каталог:

wget https://busybox.net/downloads/busybox-1.33.1.tar.bz2tar xjvf busybox-1.19.3.tar.bz2cd busybox-1.33.1/

Как и для ядра, здесь тоже требуется создать стартовую конфигурацию:

make allnoconfig

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

make menuconfig

Я выбрал следующие:

  • Settings > Build static binary (no shared libs)
  • Coreutils > cat, du, echo, ls, sleep, uname (change Operating system name to anything you want)
  • Console Utilities > clear
  • Editors > vi
  • Init Utilities > poweroff, reboot, init, Support reading an inittab file
  • Linux System Utilities > mount, umount
  • Miscellaneous Utilities > less
  • Shells > ash

Далее выход с сохранением конфигурации и переход к компиляции.

makemake install

Эта команда создаст файловую систему со всеми файлами в _install. Переместите ее в основной каталог. Лично я при этом также изменяю имя.

mv _install ../filesystem

Файловая система


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

cd ../filesystemmkdir -pv {dev,proc,etc/init.d,sys,tmp}sudo mknod dev/console c 5 1sudo mknod dev/null c 1 3

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

cat >> welcome << EOFSome welcome text...EOF

Файл Inittab, обрабатывающий запуск, выход и перезапуск:

cat >> etc/inittab << EOF::sysinit:/etc/init.d/rc::askfirst:/bin/sh::restart:/sbin/init::ctrlaltdel:/sbin/reboot::shutdown:/bin/umount -a -rEOF

И сам скрипт init:

cat >> etc/init.d/rc << EOF#!/bin/shmount -t proc none /procmount -t sysfs none /sysclearcat welcome/bin/shEOF

Сделайте init исполняемым и установите владельца всех файлов как root:

chmod +x etc/init.d/rcsudo chown -R root:root .

В завершении упакуйте директорию в один файл:

find . | cpio -H newc -o | gzip -9 > ../rootfs.cpio.gz

В правильности проделанного можете убедиться, запустив QEMU из основной директории:

qemu-system-i386 -kernel bzImage -initrd rootfs.cpio.gz

Теперь можно записывать систему на дискету.

Загрузочный образ


Создайте загрузочный файл syslinux, который будет указывать на созданное ядро и файловую систему:

cat >> syslinux.cfg << EOFDEFAULT linuxLABEL linuxSAY [ BOOTING FLOPPINUX VERSION 0.1.0 ]KERNEL bzImageAPPEND initrd=rootfs.cpio.gzEOF


chmod +x syslinux.cfg

Создайте пустой образ дискеты:

dd if=/dev/zero of=floppinux.img bs=1k count=1440mkdosfs floppinux.imgsyslinux --install floppinux.img

Смонтируйте его, после чего скопируйте туда syslinux, ядро и файловую систему:

sudo mount -o loop floppinux.img /mntsudo cp bzImage /mntsudo cp rootfs.cpio.gz /mntsudo cp syslinux.cfg /mntsudo umount /mnt

Готово!

Теперь у вас есть собственный образ дистрибутива floppinux.img, готовый к записи на дискету и загрузке на физическом устройстве.

Запись


Если у вас есть встроенный дисковод:

sudo dd if=floppinux.img of=/dev/fd0

У меня возникли сложности с записью образа на внешний дисковод из под Linux, поэтому я использовал инструмент diskwrite в Windows. Проблему я выявил позднее. Если у вас тоже USB-дисковод, то он будет отображаться как /dev/hd*. Команда на моем ПК:

sudo dd if=floppinux.img of=/dev/sdb

Весь процесс занял меньше трех минут.

1474560 bytes (1,5 MB, 1,4 MiB) copied, 164,476 s, 9,0 kB/s

Первая загрузка!


Загрузка Floppinux на Fujitsu Siemens P1610 Intel Core Solo 1.2 ГГц с 1 Гб ОЗУ:

Общая сводка


Объем диска: 1440Кб / 1.44Мб
Размер ядра: 632Кб
Инструменты: 552Кб
Оставшееся свободное место (du -h): 272Кб

Ссылки для скачивания


Если вы не хотите заморачиваться со всем этим, то просто скачайте мои файлы:

Версия 0.1.0
Голая система, готовая для кастомизации.


Запуск


<source lang="bash">qemu-system-i386 -fda floppinux.img

Версия 0.2.1


FLOPPINUX Version 0.2.0 новый логотип и загрузочный образ

Новый логотип, новый экран загрузки и в целом текстовый интерфейс. Простой интерактивный скрипт оболочки для чтения текстовых файлов. Режим KIOSK.

Подробнее об этом я написал в дополнении Floppinux Update 0.2.1


Добавление приложения


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

  • Обновите файлы в каталоге /filesystem/
  • Сожмите файл rootfs
  • Смонтируйте образ дистрибутива
  • Замените файл rootfs
  • Размонтируйте образ
  • (необязательно) запишите новый образ на дискету
  • Загрузите новую систему с обновленным ПО

Режим KIOSK


FLOPPINUX запускает любое приложение, находящееся в /home/main. Измените этот путь для запуска вашей программы.

Ресурсы


Репозиторий GitHub https://github.com/w84death/floppinux


Обсуждение (англ.)


https://news.ycombinator.com/item?id=27247612


Подробнее..

Перевод О неоправданно хорошей работе -z var

30.05.2021 18:13:46 | Автор: admin
Есть такой сабреддит /r/nononoyes, где публикуют видео, в которых происходит что-то такое, что, на первый взгляд, кажется ужасно неправильным, идущим к катастрофе. Но в конце всё, чудесным образом, заканчивается хорошо.

В том сабреддите хорошо смотрелась бы команда [ -z $var ].



Это конструкция, которая используется в bash для проверки того, является ли переменная пустой. Но тут не хватает кавычек (её более правильный вариант выглядел бы как [ -z $var ]). Это, при работе с переменными, которые могут быть пустыми, часто приводит к неприятностям.

Рассмотрим обратное выражение [ -n $var ], которое проверяет переменную на то, что она является непустой. Та же проблема с кавычками делает её полностью бесполезной:

Входные данные Ожидаемый результат [ -n $var ]
""
False
True!
"foo"
True
True
"foo bar"
True
False!

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

Нахождение результатов работы команды [ зависит от количества аргументов. Значения аргументов гораздо слабее влияют на результат. Вот упрощённая выдержка из описания POSIX-команды test, составляя которую, я не обращал внимания на отрицание:

Количество аргументов Действие Типичный пример
0 Возврат False.
[ ]
1 Возврат True, если аргумент $1 не является пустым.
[ "$var" ]
2 Применение унарного оператора $1 к $2.
[ -x "/bin/ls" ]
3 Применение бинарного оператора $2 к $1 и к $3.
[ 1 -lt 2 ]

Если это учесть становится понятным то, почему команда [ -n $var ] в двух случаях ведёт себя неправильно:

  • Когда переменная является пустой и при этом не заключена в кавычки, она удаляется, и мы передаём команде 1 аргумент литеральную строку -n. Так как -n не является пустой строкой команда выдаёт True, а должна была бы выдать False.
  • Когда переменная содержит foo bar и не заключена в кавычки, она разделяется на два аргумента, в результате мы передаём команде 3 аргумента: -n, foo и bar. Так как foo это не бинарный оператор, результатом работы команды является False (с выдачей сообщения об ошибке), а, на самом деле, результатом должно быть True.

А теперь посмотрим на то, как работает [ -z $var ]:

Входные данные Ожидаемый результат [ -z $var ] Команда test
""
True: пустая переменная
True
1 аргумент: проверка того, является ли -z непустой переменной
"foo"
False: непустая переменная
False
2 аргумента: применение -z к foo
"foo bar"
False: непустая переменная False (ошибка) 3 аргумента: применение foo к -z и bar

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

Другими словами, [ -z $var ] работает гораздо лучше, чем этого можно ожидать.

Конечно, это не значит, что я призываю всех отказаться от кавычек. Для foo bar [ -z $var ] вернёт правильный код выхода, но при этом выведет некрасивое сообщение об ошибке. Для (это строка, в которой имеются только пробелы) вернёт True, хотя должна вернуть False, так как соответствующий аргумент удаляется так, как если бы он был пустым. Bash, кроме того, что неправильно, при попытке воспользоваться механизмом внедрения кода, пропустит конструкцию var="foo -o x", так как она будет нормально воспринята командой test.

Какова мораль сей басни? Она такая же, как и всегда: не забывайте о кавычках. Даже тогда, когда кажется, что и без них всё работает как надо.

Утилита ShellCheck знает об этих особенностях. Тут можно проверить код, о котором мы говорили. А именно, анализируя конструкцию [ -n $var ], программа разразится гневным сообщением красного цвета, а рассматривая конструкцию [ -z $var ] всего лишь покажет обычное зелёное предупреждение об отсутствии кавычек.

Сталкивались ли, при работе в bash, с проблемами, связанными с кавычками?


Подробнее..

Recovery mode Сборка ядра Linux 5.12.10 c LLVM 12 Clang и LTO оптимизацией

14.06.2021 18:13:31 | Автор: admin

Технический прогресс не стоит на месте, появляются новые компьютерные архитектуры, компиляторы становятся умнее и генерируют более быстрый машинный код. Современные задачи требуют все более креативного и эффективного решения. В данной статье пойдет речь, на мой взгляд, про один из самых прогрессивных тулчейнов LLVM и компиляторы на его основе Clang и Clang++, для языков программирования С и C++ соответственно. Хоть GCC конкурент Clang, может агрессивнее оптимизировать циклы и рекурсию, Clang дает на выходе более корректный машинный код, и чаще всего не ломает поведение приложений. Плюс оптимизация программ не заканчивается только оптимизацией циклов, поэтому Clang местами дает лучшую производительность. В GCC же за счет переоптимизации вероятность получить unpredictable behavior значительно выше. По этой причине на многих ресурсах не рекомендуют использовать -O3 и LTO(Link Time Optimization) оптимизации для сборки программ. Плюс в случае агрессивной оптимизации, размер исполняемых файлов может сильно увеличиться и программы на практике будут работать даже медленнее. Поэтому мы остановились на Clang не просто так и опции компиляции -O3 и LTO работают в нем более корректно. Плюс современные компиляторы более зрелые, и сейчас уже нет тех детских болячек переоптимизации и LTO.

Что меня побудило написать эту статью? В первую очередь это несколько фактов:

  1. Впервые прочел про сборку ядра Linux с LTO оптимизацией и Clang из новостей, где упоминалась компания Google. Она использует Clang и LTO оптимизацию для сборки ядра Linux и получения лучшей производительности. Компания Google для меня является синонимом инноваций, лучших программистов в мире и поэтому для меня ее опыт является самым авторитетным. Плюс она привнесла очень много в развитие open source, и ее наработками пользуются тысячи компаний во всем мире.
  2. Хоть компания Google начала использовать Clang и LTO оптимизацию раньше, только с выходом ядра Linux 5.12.6 и 5.12.7 было закрыто большое количество багов, и сборка ядра c LTO оптимизаций стала доступна многим. До этого при сборке ядра с LTO оптимизацией многие драйвера давали сбой.
  3. Мною уже протестирована работа ядра с LTO на Ryzen 9 3900x + AMD Radeon 5700 XT. Плюс уже давно использую LLVM 12 и Clang для сборки системных программ. Инструментарий LLVM12 и Clang стали основными в моей системе по причине лучшей поддержки моего процессора и нужные мне программы работают быстрее при сборке с помощью Clang. Для программистов Clang дает лучший контроль ошибок, оптимизации и unpredictable behavior. -fdebug-macro, -fsanitize=address, -fsanitize=memory, -fsanitize=undefined, -fsanitize=thread, -fsanitize=cfi, -fstack-protector, -fstack-protector-strong, -fstack-protector-all, -Rpass=inline, -Rpass=unroll, -Rpass=loop-vectorize, -Rpass-missed=loop-vectorize, -Rpass-analysis=loop-vectorize и т.д.
  4. Данная возможность толком нигде не была описана в связи с п.2 и есть подводные моменты, которые будут рассмотрены в данной статье.


В этой статье будет описана сборка ядра Linux 5.12.10 c LLVM 12 + Clang и LTO оптимизацией. Но так как статья получилась бы короткой, то так же бонусом будет рассмотрен вопрос как сделать утилиты LLVM 12 и Clang сборочным инструментарием по умолчанию, и какие программы и библиотеки имеет смысл собрать вручную, чтобы получить лучший отклик и производительность от системы. GCC имеет более лояльную лицензию на использование, и поэтому он установлен во многих дистрибутивах по умолчанию.

Так как в новом ядре фиксится немалое количество багов для работы с моим оборудованием(Ryzen 9 3900x + AMD Radeon 5700 XT) будет рассмотрен вопрос автоматизации сборки и установки нового ядра, чтобы это сильно не отвлекало и занимало минимум времени. Думаю многим это будет полезно. Будет рассмотрен принцип работы моего сборочного скрипта. Все действия будут проводиться в Arch Linux. Если статья будет хорошо оценена, то она станет вводной частью в серию статей про оптимизацию Linux, где будут рассмотрены внутренние механизмы ОС, и как оптимизировать их работу, будут рассмотрены вредные советы и ошибки оптимизации, и будет дан ответ на вопрос оптимизации системы Что для русского хорошо, то для немца смерть!.

Хоть тема оптимизации описывалась многократно, не мало где дают вредные советы, и некоторые механизмы ОС описаны с ошибками. Чаще всего это происходит из-за сложностей перевода или минимальной документации в интернете к компонентам ядра Linux. Где-то информация вовсе устарела. Плюс некоторые вещи понимают программисты, но не понимают системные администраторы, и наоборот. Изначально после установки Linux работает относительно медленно, но благодаря оптимизации и гибкой настройке, можно добиться более высокой производительности и значительно улучшить отклик системы. Arch Linux у меня используется как основная система, и отклик системы, производительность лучше, чем в Windows 10.
Внимание, автор статьи не несет ответственность за причиненный вред в следствии использования данной статьи! Все действия вы выполняете на свой страх и риск! Все действия должны выполнять только профессионалы!


Немного теории



LTO или Link Time Optimization это оптимизация на этапе линковки(компоновки). Чтобы понять, что такое LTO рассмотрим как работают компиляторы. В большинстве компиляторов используется двух этапная модель: этап компиляции и этап линковки.

На этапе компиляции:

Парсятся исходные тексты программ, строится AST Абстрактное Синтаксическое Дерево.

  • Оптимизируется Абстрактное Синтаксическое Дерево. Оптимизируются циклы, удаляется мертвый код, результат которого нигде не используется. Раскрываются выражения, например 2+5 можно заменить на 7, чтобы при работе приложения не вычислять его значение каждый раз и тем самым сделать его быстрее и т.д.
  • Оптимизированное дерево может быть преобразовано в машинный псевдокод понятный компилятору. Псевдокод используется для дополнительной оптимизации, упрощает разработку универсального компилятора для разных архитектур процессора, например для x86-64 и ARMv7\. Так же как ASM листинг, этот псевдокод еще используется, чтобы понять, как компилятор генерирует машинный код, и служит для понимания работы компилятора, поиска ошибок, например, ошибок оптимизации и unpredictable behavior. Стоит заметить этот этап не является обязательным и в некоторых компиляторах отсутствует.
  • Происходит векторизация. Векторизация ,Automatic Vectorization, SIMD
  • Генерируется объектный файл. Объектный файл содержит в себе машинный код для компьютера, и специальные служебные структуры, в которых все еще есть неизвестные адреса функций и данных, поэтому этот файл все еще не может быть запущен на исполнение. Чтобы разрешить неизвестные адреса, был добавлен этап линковки.


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

На этапе линковки:

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


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

В Clang используется два вида LTO Оптимизации: Full LTO и Thin LTO. Full LTO это классическая реализация LTO оптимизации, которая обрабатывает конечный исполняемый файл за раз целиком и использует много оперативной памяти. Отсюда эта оптимизация занимает много времени, но дает на выходе самый быстрый код. Thin LTO это развитие LTO оптимизации, в которой нет оптимизации всего файла целиком, а вместо этого вместе с объектными файлами записывают дополнительные метаданные, и LTO оптимизатор работает с этими данными, что дает более высокую скорость получения оптимизированного исполняемого файла (скорость сравнима с линковкой файла без LTO оптимизации) и код сравнимый или чуть уступающий в производительности Full LTO. Но самое главное Full LTO может значительно увеличить размер файла, и код наоборот может из-за этого работать медленнее. Thin LTO лишен этого недостатка и в некоторых приложениях на практике мы можем получить лучшую производительность! Поэтому наш выбор будет сборка ядра Linux с Thin LTO.

Дополнительная информация:



Установка LLVM 12 и Clang



Поставить llvm и clang можно выполнив в консоли под root команду:

pacman -Syu base-devel llvm clang lld vim

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

Прошлая версия
На момент написания статьи, в дистрибутиве Arch Linux используются LLVM и Clang версии 11\. А LLVM и Clang версии 12 находятся в staging репозитории Arch Linux [LLVM](http://personeltest.ru/aways/archlinux.org/packages/staging/x86_64/llvm/). Staging репозиторий это репозиторий, где находятся версии пакетов, которые ломают приложения, зависящие от прошлой версии. Он используется для компиляции всех зависящих программ, и когда все они будут собраны, все пакеты за раз переходит в общий репозиторий. Например, в Arch Linux от LLVM и Clang версии 11 зависят blender, rust и qt creator и т.д. Если мы поставим LLVM и Clang версии 12, то они перестанут работать.
Upd. Пакет уже перешел в основной репозиторий. Так как мною одним из первых была произведена миграция на LLVM и Clang 12, то было придумано простое решение, создать пакет [llvm11-libs](http://personeltest.ru/aways/aur.archlinux.org/packages/llvm11-libs-bin/) с необходимыми библиотеками для обратной совместимости, который позволяет оставить зависимые программы рабочими. Но данный пакет работает только с моим сборочным пакетом [llvm12-git](http://personeltest.ru/aways/aur.archlinux.org/packages/llvm12-git/). Поэтому мы будем собирать LLVM и Clang 12 из исходников. Но вы можете дождаться, когда LLVM и Clang 12 появятся в основном репозитории Arch Linux или использовать 11 версию. Лично предпочитают новые версии ПО, и LLVM и Clang 12 лучше поддерживают мой процессор Ryzen 9 3900X. Плюс git версия закрыла часть багов компилятора и даже стабильнее релиза. Релизный архив с официального сайта у меня не проходит больше тестов при сборке чем git версия. Не стоит пугаться того, что часть тестов компилятор провалил, там нет критических багов для x84-64 архитектуры, и большая часть затрагивают другие компоненты, например openmp и lldb. За очень долгое время тестирования llvm и clang 12 мною не было замечено ни одного бага влияющего на работу системы. Стоит заметить, на данный момент 13 версия является очень сырой и нам не подходит!

Поставим llvm и clang 11 версии(Если 12 версия появилась в основном репозитории, то поставится 12я версия) можно выполнив в консоли под root команду:

pacman -Syu base-devel llvm clang lld libclc vim

Обновить Arch Linux и поставить новые версии программ можно командой(это будет полезно тем кто будет ждать официального выхода 12 версии, думаю это произойдет уже через пару дней):

pacman -Syu

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


Cборка LLVM 12 из Arch User Repository



Для сборки нам понадобиться git и нам надо будет собрать программу yay.

Поставим необходимые зависимости, для этого нам будут нужны права root: pacman -Syu base-devel git go vim

Если вы хотите собрать llvm 12 с помощью clang 11, то надо поставить еще их: pacman -S llvm clang

Отредактируем конфигурационный файл сборщика пакетов makepkg в Arch Linux и увеличим количество потоков для сборки программ. Это ускорит скорость сборки. Под root выполним: vim /etc/makepkg.conf

Найдем строки MAKEFLAGS и NINJAFLAGS. Нажмем латинскую букву A. Нам после -j надо указать количество потоков для сборки. Рекомендуется ставить ваше количество ядер или потоков процессора, если ядер 4, то ставим 4 или 8\. У меня это 20, 12 ядер 24 потока, 4 остаются запасными для других задач. Или используем автоматическое определение $(nproc).

В итоге получим:

MAKEFLAGS="-j20"NINJAFLAGS="-j20"

или

MAKEFLAGS="-j$(nproc)"NINJAFLAGS="-j$(nproc)"


Нажмем ESC, дальше SHIFT + :(буква Ж). Внизу появится : строка для ввода команд, вводим wq. w write, записать изменения в файл. q quit, выйти из vim. q! выход из vim без сохранения файла. Кому сложно разобраться с vim, в Linux есть замечательная программа, называется она vimtutor. Если у вас настроена правильно локаль, то vimtutor будет на русском, запустить его можно командой vimtutor. Стоит заметить, вопреки распространенному мнению, обучение у вас не займет много времени. Обычно новичков пугают мифом: vi и vim люди изучают очень долго, и осилить их могут только единицы. На самом деле это не так и там нет ничего сложного.

Под обычным пользователем клонируем репозиторий yay, собираем и устанавливаем:
git clone https://aur.archlinux.org/yay.git && cd yay && makepkg -cfi

Импортирует открытый gpg ключ, он необходим для проверки подписи llvm12-git:
gpg --keyserver pgp.mit.edu --recv-keys 33ED753E14757D79FA17E57DC4C1F715B2B66B95

Поставим LLVM 12 и библиотеки совместимости с 11 версией. Стоит заметить, мой пакет LLVM 12 уже содержит все необходимые утилиты, включая Clang и LLD и их не надо ставить отдельно. Под обычным пользователем выполним команду: yay -Syu llvm12-git. Если llvm 12 есть в официальном репозитории, то llvm11-libs-bin не нужно ставить. Команда yay задаст вам несколько вопросов, нажмите Enter в ответ на все. Сборщик LLVM задаст 3 вопроса:

  • Build with clang and llvm toolchain? Собрать с помощью llvm и clang? Отвечаем Y или Enter если да, и N если нет. Рекомендую собирать LLVM с помощью Clang.
  • Skip build tests? Пропустить сборку тестов? Отвечаем Y или Enter. Так как во время сборки, не все тесты проходят проверку, то сборка будет прекращена. Поэтому мы пропускаем сборку тестов, и на самом деле сборка будет идти даже быстрее.
  • Skip build documentation? Пропустить сборку документации? Отвечаем Y или Enter если да, и N если нет. Если вам не нужна документация, то можно пропустить, это ускорит сборку. Лучше читать документацию на официальном сайте, это удобнее.
  • Skip build OCaml and Go bindings? Пропустить сборку OCaml и Go биндингов? Отвечаем Y или Enter если да, и N если нет. Для большинства ответ Y и их сборку можно смело пропустить в угоду скорости сборки. Для тех кому они нужны, а это очень маленькое количество людей могут ответить N.


Сборка может занять от 20 минут до пары часов. Ждете и в конце отвечаете Y на вопрос: хотите ли вы поставить собранные пакеты?

После установка LLVM надо собрать libclc12-git yay -S libclc12-git. libclc необходим для компиляции opencl и для сборки mesa.

Делаем LLVM и Clang сборочным тулчейном по умолчанию в Arch Linux



Большинство программ в Arch Linux собираются с помощью команды makepkg: man makepkg и PKGBUILD файлов. Поэтому в первую очередь внесем изменения в конфигурационный файл /etc/makepkg.conf. Выполним под root в консоли команду: vim /etc/makepkg.conf. Перейдем к строке CHOST="x86_64-pc-linux-gnu" поставим курсор на следующей пустой строке и нажмем латинскую букву A, и вставим после строки:

export CC=clangexport CXX=clang++export LD=ld.lldexport CC_LD=lldexport CXX_LD=lldexport AR=llvm-arexport NM=llvm-nmexport STRIP=llvm-stripexport OBJCOPY=llvm-objcopyexport OBJDUMP=llvm-objdumpexport READELF=llvm-readelfexport RANLIB=llvm-ranlibexport HOSTCC=clangexport HOSTCXX=clang++export HOSTAR=llvm-arexport HOSTLD=ld.lld

Дальше заменим строки CPPFLAGS, CXXFLAGS, LDFLAGS на содержимое ниже:

CFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"CXXFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"

Если вкратце мы используем -O2 оптимизацию для всех программ, -fstack-protector-strong используем улучшенную защиту стека, что снижает вероятность потенциально опасных ошибок при работе со стеком в программах, она же включена у меня в ядре. Плюс на моем процессоре при сборке с Clang с -fstack-protector-strong код при работе с целыми числами работает чуть быстрее, при работе с числами с плавающей запятой есть небольшой оверхед. В GCC наоборот есть более заметный оверхед и производительность снижается. -march=native есть смысл заменить на ваш, у меня это -march=znver2 gcc.gnu.org/onlinedocs/gcc/x86-Options.html.

Изменим количество потоков в MAKEFLAGS и NINJAFLAGS для сборки программ. Это помогает ускорить сборку программ. После -j надо указать количество потоков для сборки. Рекомендуется ставить ваше количество ядер или потоков процессора, если ядер 4, то ставим 4 или 8\. У меня это 20, 12 ядер, 24 потока, 4 остаются запасными для других задач. Или используем автоматическое определение $(nproc).

В итоге получим:

MAKEFLAGS="-j20"
NINJAFLAGS="-j20"


или

MAKEFLAGS="-j$(nproc)"
NINJAFLAGS="-j$(nproc)"


Из DEBUG_CFLAGS и DEBUG_CXXFLAGS надо удалить -fvar-tracking-assignments. LLVM не поддерживает данный параметр.

Файл должен будет принять примерно такой вид:

CARCH="x86_64"CHOST="x86_64-pc-linux-gnu"CARCH="x86_64"CHOST="x86_64-pc-linux-gnu"#-- Compiler and Linker Flagsexport CC=clangexport CXX=clang++export LD=ld.lldexport CC_LD=lldexport CXX_LD=lldexport AR=llvm-arexport NM=llvm-nmexport STRIP=llvm-stripexport OBJCOPY=llvm-objcopyexport OBJDUMP=llvm-objdumpexport READELF=llvm-readelfexport RANLIB=llvm-ranlibexport HOSTCC=clangexport HOSTCXX=clang++export HOSTAR=llvm-arexport HOSTLD=ld.lldCPPFLAGS="-D_FORTIFY_SOURCE=2"CFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"CXXFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"RUSTFLAGS="-C opt-level=2"#-- Make Flags: change this for DistCC/SMP systemsMAKEFLAGS="-j20"NINJAFLAGS="-j20"#-- Debugging flagsDEBUG_CFLAGS="-g"DEBUG_CXXFLAGS="-g"#DEBUG_CFLAGS="-g -fvar-tracking-assignments"#DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"#DEBUG_RUSTFLAGS="-C debuginfo=2"

Нажмем ESC, дальше SHIFT + :(буква Ж). Внизу появится: строка для ввода команд, вводим wq. w write, записать изменения в файл. q quit, выйти из vim. q! выход из vim без сохранения файла. Кому сложно разобраться с vim, в Linux есть замечательная программа, называется она vimtutor. Если у вас настроена правильно локаль, то vimtutor будет на русском, запустить его можно командой `vimtutor`. Стоит заметить, вопреки распространенному мнению, обучение у вас не займет много времени. Обычно новичков пугают мифом: vi и vim люди изучают очень долго, и осилить их могут только единицы. На самом деле это не так и там нет ничего сложного.

Следующим этапом можно добавить настройки в файл .bashrc текущего пользователя. Не root, сборка программ под root очень плохая идея! Это относительно вредный совет и с помощью clang будут собираться все программы! Поэтому делайте это только если хорошо понимаете зачем это вам. Это можно сделать командой:

cat << 'EOF' >> "${HOME}/.bashrc"export CARCH="x86_64"export CHOST="x86_64-pc-linux-gnu"export CC=clangexport CXX=clang++export LD=ld.lldexport CC_LD=lldexport CXX_LD=lldexport AR=llvm-arexport NM=llvm-nmexport STRIP=llvm-stripexport OBJCOPY=llvm-objcopyexport OBJDUMP=llvm-objdumpexport READELF=llvm-readelfexport RANLIB=llvm-ranlibexport HOSTCC=clangexport HOSTCXX=clang++export HOSTAR=llvm-arexport HOSTLD=ld.lldexport CPPFLAGS="-D_FORTIFY_SOURCE=2"export CFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"export CXXFLAGS="-fdiagnostics-color=always -pipe -O2 -march=native -fstack-protector-strong"export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"export RUSTFLAGS="-C opt-level=2"export MAKEFLAGS="-j20"export NINJAFLAGS="-j20"export DEBUG_CFLAGS="-g"export DEBUG_CXXFLAGS="-g"EOF


Список системных библиотек и программ которые стоит собирать вручную


Внимание, сборка всех программ и все консольные команды надо выполнять под обычным пользователем, перед установкой у вас попросит пароль root. Сборка всех библиотек и программ из списка не занимает много времени. Все кроме Mesa у меня собирается в районе 1 минуты. Список дан в той в последовательности в которой рекомендуется сборка! К примеру от zlib-ng и zstd зависит Mesa, а от Mesa зависит xorg-server.

Самое первое, что надо сделать в Arch Linux это заменить zlib на zlib-ng. Это дает хороший выигрыш производительности в приложениях, которые зависят от zlib. Больше всего это заметно на веб браузерах и веб серверах, которые используют gzip сжатие для передачи данных. На высоко нагруженных серверах это дает очень значительную прибавку к производительности. Сборка довольно быстрая. Поставить можно командой(под обычным пользователем): yay -Syu zlib-ng. На вопрос хотите ли вы удалить zlib отвечайте Y. Не бойтесь библиотеки полностью взаимозаменяемы, и ничего не сломается!

Дальше у нас идет zstd это вторая по популярности библиотека используемая в ядре и в программах для сжатия данных. Поэтому имеет смысл собрать так же ее. Чтобы собрать, вам нужно скопировать содержимое zstd, создать директорию, например zstd, а в ней создать файл PKGBUILD и в него вставить содержимое по ссылке. Дальше в консоли перейти в директорию содержащую PKGBUILD, выполнить команду makepkg -cfi .

libjpeg-turbo Библиотека для работы c jpeg файлами. Ее очень часто используют браузеры и программы рабочего стола. libjpeg-turbo собранный с clang дает у меня лучшую производительность. Действия такие же, как в zstd. Создать директорию, и вставить в файл PKGBUILD содержимое по ссылке libjpeg-turbo. Дальше в консоли перейдите в директорию содержащую PKGBUILD, выполнить команду makepkg -cfi.

libpng Библиотека для работы с PNG файлами. По сборке и установке все то же самое. libpng. Для сборки вам понадобится патч: 72fa126446460347a504f3d9b90f24aed1365595.patch, его надо положить в одну директорию с файлом PKGBUILD. Для сборки надо внести изменения в PKGBUILD, заменить source и sha256sums на строки ниже, и добавить функцию prepare.

source=("https://downloads.sourceforge.net/sourceforge/$pkgname/$pkgname-$pkgver.tar.xz"  "72fa126446460347a504f3d9b90f24aed1365595.patch")sha256sums=('505e70834d35383537b6491e7ae8641f1a4bed1876dbfe361201fc80868d88ca'  '84298548e43976265f414c53dfda1b035882f2bdcacb96ed1bc0a795e430e6a8')prepare() {  cd $pkgname-$pkgver  patch --forward --strip=1 --input="${srcdir:?}/72fa126446460347a504f3d9b90f24aed1365595.patch"}


Mesa это святой грааль для всех графических приложений. Стоит собирать всегда вручную, дает хорошую прибавку в десктоп приложениях, улучшается отклик рабочего стола. Одно время сидел на git версии, чтобы получить лучшую поддержку новых видеокарт AMD. Вот мой PKGBUILD оптимизированный для сборки с помощью Clang.

Для сборки вам надо отредактировать файл mesa.conf и установить необходимые вам драйвера dri, gallium, vulkan для сборки. У меня сборка только под новые видеокарты AMD. Подглядеть можно тут: Mesa OpenGL, mesa-git package, Mesa Documentation. При выходе новой версии Mesa не забудьте сменить 21.1.2 на новую версию. А после смены версии обновите контрольные суммы файлов, выполнив в директории с PKGBUILD команду updpkgsums.

xorg-server X сервер с которым взаимодействуют почти все среды рабочего стола. Сборка дает заметное улучшение отклика рабочего стола. Сборка такая же через mapkepkg -cfi. Скачать необходимые файлы для сборки можно тут: xorg-server Сборочный пакет немного кривой и собирает пакет без оптимизаций. Поэтому его надо пропатчить. Для это после строки arch-meson ${pkgbase}-$pkgver build \ надо добавить строки:

  -D debug=false \  -D optimization=2 \  -D b_ndebug=true \  -D b_lto=true \  -D b_lto_mode=thin \  -D b_pie=true \

Полный список критических важных программ влияющих на производительность системы вы можете посмотреть в поем github репозитории arch-packages. Список был создан с помощью системного профилировщика perf. Все сборочные файлы оптимизированы для сборки с помощью llvm и сборка полностью автоматизирована. На моем ryzen 9 3900x сборка всего занимает около 20 минут. Единственный пакет который невозможно собрать с помощью clang и llvm это glibc. Его надо собирать вручную, и с оптимизацией -march= под ваш процессор, это самая часто вызываемая библиотека. Сборку glibc могут проводить только профессионалы, понимающие, что они делают. Не правильная сборка может сломать систему!

Для того, что бы воспользоваться автоматизированной сборкой надо выполнить(под обычным пользователем):
git clone https://github.com/h0tc0d3/arch-packages.git && cd arch-packages && chmod +x build.sh

Дальше нам надо установить все gpg сертификаты и зависимости необходимые для сборки, выполним ./build.sh --install-keys, а затем ./build.sh --install-deps

Для сборки программ достаточно просто запустить скрипт: ./build.sh --install, скрипт вам будет задавать вопросы, какие программы хотите собрать и поставить. На вопрос: хотите ли вы отправить все ваши деньги и пароли автору статьи? хотите ли вы заменить программы?(например, zlib-ng и zlib конфликтуют. Удалить zlib? [y/N] ) ответьте Y . Если вам нужна принудительная пересборка всех программ, то надо выполнить ./build.sh --install --force. По умолчанию, если пакет был уже собран и найден с нужной версией, то он не собирается, а просто устанавливается.

Для сборки mesa надо отредактировать файл mesa/mesa.conf и установить необходимые вам драйвера dri, gallium, vulkan для сборки.

С помощью команды ./build.sh --check можно проверить различия версий в моем репозитории и в официальном, помогает быстро адаптировать сборочные файлы и собрать актуальные версии программ. Слева версия в моем репозитории, справа от стрелки в официальном. Мой репозиторий может служить удобной тренировочной точкой на пути к созданию своего дистрибутива, создания LFS и развитию навыка пересборки ПО не ломая систему.

[+] zstd 1.5.0-1[+] libpng 1.6.37-3[+] libjpeg-turbo 2.1.0-1[+] mesa 21.1.2-1[+] pixman 0.40.0-1[-] glib2 2.68.3-1 -> 2.68.2-1[+] gtk2 2.24.33-2[+] gtk3 1:3.24.29-2[+] gtk4 1:4.2.1-2[+] qt5-base 5.15.2+kde+r196-1[+] icu 69.1-1[+] freetype2 2.10.4-1[+] pango 1:1.48.5-1[+] fontconfig 2:2.13.93-4[+] harfbuzz 2.8.1-1[+] cairo 1.17.4-5[+] wayland-protocols 1.21-1[+] egl-wayland 1.1.7-1[+] xorg-server 1.20.11-1[+] xorgproto 2021.4-1[+] xorg-xauth 1.1-2[+] xorg-util-macros 1.19.3-1[+] xorg-xkbcomp 1.4.5-1[+] xorg-setxkbmap 1.3.2-2[+] kwin 5.22.0-1[+] plasma-workspace 5.22.0-2[+] glibc 2.33-5


Сборка Ядра с помощью LLVM и Clang с LTO оптимизацией


Внимание! Сборку ядра необходимо выполнять под обычным пользователем. Перед установкой ядра у вас попросит sudo пароль. Не рекомендуется использовать патчи ядра linux-ck, linux-zen, MuQSS и т.д. Мною были протестированы все, при кажущемся увеличении производительности системы, происходят кратковременные лаги и снижается стабильность системы, некоторые подсистемы ядра работают не стабильно! С выходом ядра 5.11 стандартный планировщик работает не хуже и значительно стабильнее! Единственный патч который мною применяется это патч для применения оптимизации под процессор github.com/graysky2/kernel_gcc_patch Выбрать ваш процессор можно в меню конфигуратора ядра Processor type and features-->Processor family.

Сборка ядра с помощью LLVM описана в официальной документации Linux Kernel Build with LLVM. Но там есть несколько подводных моментов, которые не описаны. Первый подводный момент заключается в OBJDUMP=llvm-objdump, тут идет переопределение objdump, но так как параметры objdump в llvm имеет другой синтаксис, то при сборке будет пропущена часть тестов для проверки корректности сборки, и будет warning ругающийся на objdump. Правильно будет оставить родной objdump OBJDUMP=objdump

Неправильно:

make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \  READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ \  HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump


Правильно:

make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \  READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ \  HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=objdump

Второй подводный момент заключается в том, что если мы не добавим LLVM_IAS=1 в строку make, то нам не будет доступна LTO оптимизация в конфигураторе ядра!

Поэтому полная строка для сборки с LTO будет:

export BUILD_FLAGS="LLVM=1 LLVM_IAS=1 CC=clang CXX=clang++ LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=objdump"make ${BUILD_FLAGS} -j$(nproc)

Полный список команд для сборки ядра. /tmp
надо заменить на вашу директорию куда будут распакованы исходные файлы ядра, а mykernel
надо заменить на ваш постфикс для имени ядра.

export BUILD_FLAGS="LLVM=1 LLVM_IAS=1 CC=clang CXX=clang++ LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld OBJCOPY=llvm-objcopy OBJDUMP=objdump"tar -xf linux-5.12.10.tar.xz -C /tmpcd /tmp/linux-5.12.10zcat /proc/config.gz > .config # Берем конфигурацию запущенного ядра из /proc/config.gz и используем ее для сборкиecho "-mykernel" > .scmversionmake ${BUILD_FLAGS} oldconfigmake ${BUILD_FLAGS} -j$(nproc) nconfig

C помощью oldconfig конфигурация адаптируется под новое ядро и запускается конфигуратор nconfig. Подробнее о конфигураторах ядра можно прочесть в официальной документации [Kernel configurator](http://personeltest.ru/aways/www.kernel.org/doc/html/latest/kbuild/kconfig.html).

В конфигураторе переходим в General architecture-dependent option --> Link Time Optimization (LTO) и выбираем Clang ThinLTO (EXPERIMENTAL). Для дополнительной защиты стека в General architecture-dependent options ставим \* напротив Stack Protector buffer overflow detection и Strong Stack Protector. Жмем F9 и сохраняем новый конфигурационный файл. Далее идет список команд для сборки и установки нового ядра.

make ${BUILD_FLAGS} -j$(nproc)make ${BUILD_FLAGS} -j$(nproc) modulessudo make ${BUILD_FLAGS} -j$(nproc) modules_installsudo cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-mykernel

Следующий подводный момент заключается в DKMS, после установки ядра собранного с помощью Clang, DKMS пытается собрать модули ядра с помощью GCC. По этой причине сборка и установка DKMS модулей в новое ядро завершается ошибкой. Решение проблемы заключается в передаче DKMS компилятора Clang таким образом:

sudo ${BUILD_FLAGS} dkms install ${dkms_module} -k 5.12.10-mykernel


Автоматизация сборки ядра Linux



Для автоматизации сборки ядра мы будем использовать мой bash скрипт github.com/h0tc0d3/kbuild. Клонируем репозиторий и перейдем в рабочую директорию: git clone https://github.com/h0tc0d3/kbuild.git && cd kbuild && chmod +x kbuild.sh

Отредактируем файл build.sh или поместим содержимое ниже в файл ${HOME}/.kbuild. Рекомендуется второй способ vim "${HOME}/.kbuild" т.к. при обновлении скрипта наши настройки сохранятся. Если использовалось клонирование репозитория git, то в директории со скриптом можно выполнить команду git pull, чтобы обновить скрипт. Ниже даны параметры по умолчанию, они формируют поведение скрипта по умолчанию, если соответствующий параметр не был передан. Эти параметры в дальнейшем можно будет переопределить с помощью параметров командной строки для скрипта. Так же можно добавить команду в ваш .bashrc. Для этого в директории со скриптом kbuild.sh надо выполнить echo "alias kbuild='${PWD}/kbuild.sh" >> "${HOME}/.bashrc", ${PWD} автоматом заменит на текущую директорию. Или из любой другой директории можно указать полный пусть к скрипту echo "alias kbuild='полный-путь/kbuild.sh'" >> "${HOME}/.bashrc" После редактирования .bashrc необходимо перезапустить терминал! Теперь можно будет запускать скрипт командой kbuild --help .

KERNEL_VERSION='5.12.10'         # Версия Linux для сборки. Любая версия с официального сайта kernel.org, включая rc версии.KERNEL_POSTFIX='noname'         # Постфикс для названия ядра. Ядро будет иметь имя версия-постфикс, 5.12.10-noname, нужно для разделения в системе ядер с одной версией.KERNEL_CONFIG='/proc/config.gz' # Конфигурационный файл ядра. Поддерживает любые текстовые файлы и с жатые с расширением gz.KERNEL_CONFIGURATOR='nconfig'   # Конфигуратор ядра nconfig, menuconfig, xconfig.# Рекомендую использовать nconfig, он лучше menuconfig.# Можно писать полную строку, например MENUCONFIG_COLOR=blackbg menuconfig# Дополнительную информацию можно найти в документации к ядру https://www.kernel.org/doc/html/latest/kbuild/kconfig.htmlMKINITCPIO=1 # Запускать "mkinitcpio -p конфигурационный_файл" После сборки? 0 - Нет, 1 - Да.MKINITCPIO_CONFIG="${KERNEL_POSTFIX}" # Имя конфигурационного файла mkinitcpio, по умолчанию равно постфиксу.CONFIGURATOR=0      # Запускать конфигуратор ядра? 0 - Нет, 1 - Да. Если вам не нужно конфигурировать ядро, то можно поставить 0.LLVM=0              # Использовать LLVM Для сборки? 1 - Да, 0 - Нет(Будет использован GCC или другой системный компилятор по умолчанию)THREADS=8           # Количество поток для сборки. Ускоряет сборку. Для автоматического определения надо заменить на $(nproc)BUILD_DIR='/tmp'    # Директория в которой будет проходить сборки ядра. У меня 32gb оперативной памяти и сборка происходит в tmpfs.DOWNLOAD_DIR=${PWD} # Директория для сохранения архивных файлов с исходниками ядра. ${PWD} - в папке из которой запущен скрипт сборки.DIST_CLEAN=0    # Если директория с исходниками существует выполнять make disclean перед сборкой? 0 - Нет, 1 - ДаCLEAN_SOURCE=0  # Выполнять make clean после сборки ядра? 0 - Нет, 1 - ДаREMOVE_SOURCE=1 # Удалять директорию с исходными файлами ядра после сборки? 0 - Нет, 1 - Да.SYSTEM_MAP=0    # Копировать System.map в /boot После сборки? 0 - Нет, 1 - Да.PATCH_SOURCE=1                          # Применять патчи ядра? 0 - Нет, 1 - Да.PATCHES=("${HOME}/confstore/gcc.patch") # Список патчей ядра. Нельзя поменять с помощью параметров скрипта.DKMS_INSTALL=1                                        # Выполнять DKMS Install? 0 - Нет, 1 - Да.DKMS_UNINSTALL=1                                      # Выполнять DKMS Uninstall? 0 - Нет, 1 - Да.DKMS_MODULES=('openrazer-driver/3.0.1' 'digimend/10') # Список DKMS модулей, который нужно собрать и установить. Нельзя поменять с помощью параметров скрипта.

Внимание! Сборку ядра необходимо выполнять под обычным пользователем. Перед установкой ядра у вас попросит sudo пароль. Не рекомендуется использовать патчи ядра linux-ck, linux-zen, MuQSS и т.д. Мною были протестированы все, при кажущемся увеличении производительности системы, происходят кратковременные лаги и снижается стабильность системы, некоторые подсистемы ядра работают не стабильно. С выходом ядра 5.11 стандартный планировщик работает не хуже и значительно стабильнее! Единственный патч который мною применяется это патч для применения оптимизации под процессор github.com/graysky2/kernel_gcc_patch. Нас интересует файл more-uarches-for-kernel-5.8+.patch. Путь к нему имеет смысл указать в PATCHES. Выбрать ваш процессор можно в меню конфигуратора ядра Processor type and features-->Processor family.

Принцип работы скрипта:

1) set -euo pipefail скрипт переходит в строгий режим, в случае ошибок скрипт завершается с ошибкой. Является хорошим тоном, при написании bash скриптов. Скрипт проверяет запущен ли он под рут, если запущен под рут, то выдает ошибку и завершается. Загружается настройки пользователя из файла ${HOME}/.kbuild

2) Скрипт проверяет существование директории linux-версия в директории BUILD_DIR. Если существует, то исходники распакованы. Перед сборкой может выполняться команда make distclean, поведение задается переменной DIST_CLEAN. Если этой директории не существует, то проверяется существование файла linux-версия.tar.gz

или linux-версия.tar.xz. Если файл найден, то он распаковывается в BUILD_DIR. Иначе файл скачивается с kernel.org в директорию DOWNLOAD_DIR.

3) Скрипт применяет патчи ядра и устанавливает постфикс для версии ядра(записывает его в файл .scmversion ).

4) Скрипт копирует настройки ядра из файла KERNEL_CONFIG в .config и выполняет make oldcofig для адаптации настроек под новое ядро и запускает конфигуратор ядра.

5) Скрипт собирает ядро и модули.

6) Скрипт удаляет модули DKMS из ядра которое сейчас запущено, если это необходимо. Это необходимо, чтобы в списке dkms status не отображались мертвые ядра. Удаляет директорию `/lib/modules/версия-постфикс` если она существует. Она существует в том случае, если мы собираем одну и туже версию несколько раз. Это дополнительная защита от unpredictable behavior .

7) Скрипт устанавливает модули ядра, копирует ядро в /boot/vmlinuz-постфикс.

8) Скрипт собирает DKMS модули и устанавливает их. Копирует System.map в /boot/System-постфикс.map, если это необходимо.

9) Обновляет загрузочный img файл для ядра. Выполняет mkinitcpio -p конфиг.

10) Выполняет make clean если необходимо. Удаляет директорию linux-версия в директории BUILD_DIR, если это необходимо.

Собрать ядро с llvm можно командой ./kbuild.sh -v 5.12.10 --llvm --start или kbuild -v 5.12.10 --llvm --start, если был установлен alias. -v 5.12.10 указывает версию ядра для сборки, --llvm указывает собирать ядро с помощью llvm и clang. --start указывает, что надо запускать конфигуратор ядра. Получить справку по параметрам скрипта можно выполнив команду kbuild --help.

Русская справка
Параметры: Описание: Пример:
--version, -v Версия ядра для сборки --version 5.12.10 | -v 5.13-rc4
--postfix, -p Постфикс ядра --postfix noname | -p noname
--config, -c Файл конфигурации ядра --config /proc/config.gz | -c /proc/config.gz
--dir, -d Директории сборки --dir /tmp | -d /tmp
--download, -z Директория загрузки --download /tmp | -z /tmp
--threads, -t Количество потоков сборки --threads 8 | -t 8
--configurator, -x Конфигуратор ядра --configurator nconfig | -x "MENUCONFIG_COLOR=blackbg menuconfig"

--start, -s Запускать конфигуратор
--disable-start, -ds Не запускать конфигуратор

--mkinitcpio, -mk Запускать mkinitcpio после установки ядра
--disable-mkinitcpio, -dmk Не запускать mkinitcpio после установки ядра
--mkinitcpio-config, -mc Конфиг mkinitcpio --mkinitcpio-config noname | -mc noname

--llvm, -l Использовать LLVM
--disable-llvm, -dl Не использовать LLVM

--patch, -ps Применять патчи ядра
--disable-patch, -dp Не применять патчи ядра

--map, -m Копировать System.map в /boot/System-постфикс.map
--disable-map, -dm Не копировать System.map

--clean, -cs Чистить исходники после сборки. make clean
--disable-clean, -dc Не чистить исходники после сборки.
--distclean, -cd Чистить исходники перед сборкой. make distclean
--disable-distclean, -dd Не чистить исходники перед сборкой.
--remove, -r Удалять директорию с исходниками после сборки
--disable-remove, -dr Не удалять директорию с исходниками после сборки

--dkms-install, -di Устанавливать DKMS модули
--disable-dkms-install, -ddi Не устанавливать DKMS модули
--dkms-uninstall, -du Деинсталлировать DKMS модули перед их установкой
--disable-dkms-uninstall, -ddu Не деинсталлировать DKMS модули перед их установкой

Список параметров которые помогают отлавливать ошибки на разных этапах и продолжить вручную:

--stop-download, -sd Стоп посл загрузки файла
--stop-extract, -se Стоп после распаковки архива с исходниками
--stop-patch, -sp Стоп после применения патчей ядрей
--stop-config, -sc Стоп после конфигуратора ядра
--stop-build, -sb Стоп после сборки ядра
--stop-install, -si Стоп после установки нового ядра и модулей




Как можно понять из статьи сборка ядра с LLVM и Clang относительно простая. И самое главное можно автоматизировать сборку и установку ядра, и в дальнейшем не тратить много времени на сборку новых ядер.

Всем кто дочитал до конца, спасибо! Комментарии и замечания приветствуются!


Подробнее..

Превращаем одноплатник Cubietruck в Wi-Fi Hotspot с Captive portal, VPN-шлюзом и Ad block

25.05.2021 10:11:06 | Автор: admin
raspap

Для построения Wi-Fi сети обычно используют готовые маршрутизаторы, функционал которых всегда ограничен прошивкой. А если необходимо добавить блокировщик рекламы, VPN шлюз и красивый Captive portal, покупать новую железку? Стоимость устройства с таким функционалом будет уже весьма высока. Можно взять Linux с Hostapd и сделать точку доступа с Wi-Fi, но в отличие от готовых маршрутизаторов не будет наглядного Web-интерфейса. И для решения этой задачи был создан проект RaspAP, который на базе устройств с ОС Debian создает Wi-Fi Hotspot с Captive portal, VPN-шлюзом, Ad block. Для RaspAP в отличие от OpenWrt не требуется непосредственная поддержка устройства, достаточно поддержки последней версии Debian. RaspAP работает поверх уже установленных ОС: Raspberry Pi OS, Armbian, Debian, Ubuntu. Как сделать Wi-Fi Hotspot на RaspAP прошу под кат.

RaspAP open-source проект создания беспроводного маршрутизатора из многих популярных устройств работающих на ОС Debian, включая Raspberry Pi. Содержит удобный Web-интерфейс для настройки, блокировщик рекламы, осуществляет шлюзование сетевого трафика через OpenVPN или WireGuard.

Используя RaspAP можно быстро развернуть Hotspot с доступом в сеть Интернет, где угодно: в магазине или торговом центре, заправке, кафе и ресторане, библиотеке, больнице, аэропорте и вокзале, а также в совершенно непривычных, уединенных местах, например на вершине горы. Благодаря наличию Captive portal, посетители подключаясь к Сети, обязательно увидят информацию, которую владелец Wi-Fi желает довести до пользователей. Это может быть информация о соглашение использования публичного hotspot, и т.д.

Поддерживаемые устройства и ОС


Для устройств на ARM-архитектуре заявлена официальная поддержка, устройства на x86 процессорах в настоящее время находится в стадии Beta.

raspap

Поддерживаемые ОС и архитектуры RaspAP

Базовой платформой работы RaspAP является устройство Raspberry Pi. Но благодаря поддержки Armbian на основе Debian, список поддерживаемых устройств становится весьма широким.

Wi-Fi Hotspot на RaspAP будет развернут на одноплатном компьютере Cubietruck, процессор AllWinner A20 (ARM32), с ОС Armbian (на базе Debian). Для задач маршрутизации сетевого трафика для нескольких клиентов процессора AllWinner A20 с двумя ядрами Cortex-A7 будет недостаточно, но вы можете взять гораздо более мощное устройства из каталога поддерживаемых проектом Armbian.

RaspAP


raspap

Под капотом RaspAP использует hostapd, dnsmasq, iptables, веб-интерфейс работает на lighttpd с php-скриптами. С точки зрения использования новых функций применяется политика спонсорства. Если оформить ежемесячное спонсорство, то ваш аккаунт на GitHub будет добавлен в группу Insiders, которые первыми получают возможность протестировать новые функции. Функции доступные на данный момент только спонсорам будут помечены Insiders Edition.

raspap

Веб-интерфейс RaspAP

Возможности RaspAP:

  • Графический интерфейс для настройки и отображения графиков активности клиентских устройств;
  • Поддержка сертификатов SSL;
  • Интеграция с Captive portal;
  • Управление DHCP-сервером;
  • Поддержка адаптеров 802.11ac 5 ГГц;
  • Автоопределение внешних беспроводных адаптеров.

Пройдемся коротко по основным функциям RaspAP.

Точка доступа


По умолчанию создается точка доступа со следующими параметрами:

  • Interface: wlan0
  • SSID: raspi-webgui
  • Wireless Mode: 802.11n 2.4GHz
  • Channel: 1
  • Security Type: WPA2
  • Encryption Type: CCMP
  • Passphrase: ChangeMe

К AP можно подключаться по ключевой паре SSID + пароль или по QR-коду. В случае бездействия клиента, AP может его отключить (требуется поддержка в драйверах). В Insiders Edition доступна возможность изменять мощность в dBm. Для обеспечения гарантированной работы можно задать ограниченное количество подключаемых клиентов.

Для Raspberry Pi Zero W доступен режим виртуализации беспроводного устройства. Единственное на борту Wi-Fi устройство будет работать в режиме клиента и точки доступа. Режим виртуализации сетевых интерфейсов работает и на других адаптерах USB Wi-Fi таких как RTL8188.

Блокировщик рекламы (Ad blocking)


Блокирует ads, трекеры и узлы из черного списка. В качестве источника черного списка выступает проект notracking, список обновляется автоматически. Блокируются следующие типы узлов: tracking, поставщики рекламы, сбор аналитики, фишинговые и мошенические сайты, содержащие вредоносные программы, веб-майнеры.

Captive portal


raspap

Captive portal

Из коробки интегрирован nodogsplash. nodogsplash легкое и простое решения создания кастомизируемых порталов. Поддерживает различные политики работы клиентов.

Поддержка дисплея для вывода состояния работы


Статистическую работу можно выводить на TFT-экран Adafruit Mini PiTFT контроллер ST7789. Скрипт вывода информации написан на Python, поэтому программный код можно легко адаптировать и для другого дисплея, например для ILI9341.

raspap

Вывод информации о работе AP

Поддержка различных сетевых устройств в качестве WAN-интерфейса (Insiders Edition)


В качестве доступа к сети Интернет, RaspAP поддерживает несколько различных типов сетевых устройств, такие как:

  • Ethernet interface (eth);
  • Wireless adapter (wlan);
  • Mobile data modem (ppp);
  • Mobile data adapter with built-in router;
  • USB connected smartphone (USB tethering);

Это особенно удобно когда вы путешествуете или работает в полевых условиях.

OpenVPN


raspap

Сетевой трафик можно туннелировать используя клиента OpenVPN. В Insiders Edition доступна возможность хранения нескольких профилей OpenVPN с функцией быстрого переключения между ними.

WireGuard (Insiders Edition)


raspap

WireGuard быстрый и современный VPN, в котором используется самая современная криптография. Он более производителен, чем OpenVPN, и обычно считается наиболее безопасным, простым в использовании и самым простым решением VPN для современных дистрибутивов Linux. Благодаря низкому overhead, если устройство работает от батареи, то время работы при использование WireGuard будет больше, чем при использование OpenVPN.

Доступ к Web-интересу настроек через SSL


raspap

Для защиты сетевого трафика от перехвата, доступно шифрование по SSL в пределах локальной сети. Проект mkcert позволяет в несколько простых шагов развернуть корневой центр сертификации и генерировать сертификаты, подписанные вашим собственным частным ЦС.

Постановка задачи


Установка RaspAP будет произведена из публичного репозитория, на Cubietruck установлена последняя версия Armbian (на основе Debian): Armbian 21.02.3 Buster, Linux 5.10.21-sunxi. На борту имеется встроенный адаптер wlan0, будет выступать в качестве клиентского доступа к сети Интернет (WAN-интерфейс). Для Hotspot подключим RTL8188 USB WiFi dongle wlan1.

  • IP конфигурация для wlan0: address 192.168.43.12 netmask 255.255.255.0 gateway 92.168.43.1.
  • IP конфигурация для wlan1: address 10.3.141.1 netmask 255.255.255.0 gateway 10.3.141.1.

Конфигурация DHCP-сервера:

  • Диапазон выдаваемых IP-адресов 10.3.141.50 10.3.141.254;
  • Шлюз/DNS-сервер: 10.3.141.1.

Для шлюзования сетевого трафика через OpenVPN установим на VPS сервер SoftEther VPN Server. SoftEther VPN Server мультипротокольный VPN-сервер, который может поднимать L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP-серверы, а также имеет свой собственный протокол SSL-VPN, который неотличим от обычного HTTPS-трафика (чего не скажешь про OpenVPN handshake, например), может работать не только через TCP/UDP, но и через ICMP (подобно pingtunnel, hanstunnel) и DNS (подобно iodine), работает быстрее (по заверению разработчиков) текущих имплементаций, строит L2 и L3 туннели, имеет встроенный DHCP-сервер, поддерживает как kernel-mode, так и user-mode NAT, IPv6, шейпинг, QoS, кластеризацию, load balancing и fault tolerance, может быть запущен под Windows, Linux, Mac OS, FreeBSD и Solaris и является Open-Source проектом под GPLv2.

Для VPS сервера выберем тариф на vdsina.ru за 330 р./месяц, в который включена квота на 32 ТБ трафика, чего более чем достаточно. SoftEther VPN Server будет развернут в Docker контейнере, поэтому выбор ОС CentOS/Debian/Ubuntu не принципиально важен.

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

raspap

VPS сервер на vdsina.ru

Сервер был развернут в Московской локации, IP-адрес 94.103.85.152, dns-имя: v636096.hosted-by-vdsina.ru. Подключение к серверу будет по DNS имени.

raspap

Итоговая схема сети

Как будет выглядеть Web-интерфейс RaspAP и подключение к Hotspot


Подключение к AP SSID: raspi-webgui


Подключение к AP raspi-webgui

Конфигурационные файлы RaspAP


Для установки RaspAP есть Quick installer, но он выполняется без задания параметров и wlan0 настроен как Hotspot, что нам не подходит. Поэтому воспользуемся Manual installation, с некоторыми изменениями т.к. руководство содержит некоторые ошибки и сам RaspAP работает с некоторыми некритичными багами, из-за этого пришлось немного больше потратить время на установку. О багах будет в ходе установки.

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

Список конфигурационных файлов (GitHub):

  • hostapd.conf служба hostapd
  • default_hostapd служба hostapd
  • 090_raspap.conf служба dnsmasq.d
  • 090_wlan1.conf служба dnsmasq.d
  • defaults.json служба raspap
  • dhcpcd.conf служба raspap
  • config.php портал конфигурации RaspAP

hostapd.conf служба hostapd

Содержит настройки AP по умолчанию такие как: ssid, channel, password и т.д.

hostapd.conf
driver=nl80211ctrl_interface=/var/run/hostapdctrl_interface_group=0beacon_int=100auth_algs=1wpa_key_mgmt=WPA-PSKssid=raspi-webguichannel=1hw_mode=gwpa_passphrase=ChangeMeinterface=wlan1wpa=2wpa_pairwise=CCMPcountry_code=RU## Rapberry Pi 3 specific to on board WLAN/WiFi#ieee80211n=1 # 802.11n support (Raspberry Pi 3)#wmm_enabled=1 # QoS support (Raspberry Pi 3)#ht_capab=[HT40][SHORT-GI-20][DSSS_CCK-40] # (Raspberry Pi 3)## RaspAP wireless client AP mode#interface=uap0## RaspAP bridge AP mode (disabled by default)#bridge=br0



default_hostapd служба hostapd

Настройка службы hostapd, параметр DAEMON_CONF определяет путь к настройкам.

default_hostapd
# Location of hostapd configuration fileDAEMON_CONF="/etc/hostapd/hostapd.conf"



090_raspap.conf служба dnsmasq.d

Настройка службы dnsmasq, параметр conf-dir определяет путь к настройкам.

090_raspap.conf
# RaspAP default configlog-facility=/tmp/dnsmasq.logconf-dir=/etc/dnsmasq.d


090_wlan1.conf служба dnsmasq.d

Настройка dnsmasq для сетевого интерфейса wlan1. Содержит диапазон выдаваемых IP-адресов, и другие сетевые настройки. Необходимо обратить внимание на название файла по маске 090_[ИДЕНТИФИКАТОР_ИНТЕРФЕЙСА_HOTSPOT].conf. Если у вас сетевой интерфейс для hostspot будет назваться например wlan2, то следует задать название файла 090_wlan2.conf.

090_wlan1.conf
# RaspAP wlan0 configuration for wired (ethernet) AP modeinterface=wlan1domain-neededdhcp-range=10.3.141.50,10.3.141.255,255.255.255.0,12hdhcp-option=6,10.3.141.1


defaults.json служба raspap

Настройка DHCP серверов для интерфейсов wlan0 и wlan1.

defaults.json
{  "dhcp": {    "wlan1": {       "static ip_address": [ "10.3.141.1/24" ],      "static routers": [ "10.3.141.1" ],      "static domain_name_server": [ "10.3.141.1" ],      "subnetmask": [ "255.255.255.0" ]    },    "wlan0": {      "static ip_address": [ "192.168.43.12/24" ],      "static routers": [ "192.168.43.1" ],      "static domain_name_server": [ "1.1.1.1 8.8.8.8" ],      "subnetmask": [ "255.255.255.0" ]    },    "options": {      "# RaspAP default configuration": null,      "hostname": null,      "clientid": null,      "persistent": null,      "option rapid_commit": null,      "option domain_name_servers, domain_name, domain_search, host_name": null,      "option classless_static_routes": null,      "option ntp_servers": null,      "require dhcp_server_identifier": null,      "slaac private": null,      "nohook lookup-hostname": null    }  },  "dnsmasq": {    "wlan1": {      "dhcp-range": [ "10.3.141.50,10.3.141.255,255.255.255.0,12h" ]    },    "wlan0": {      "dhcp-range": [ "192.168.43.50,192.168.50.150,12h" ]    }  }}


dhcpcd.conf служба raspap

Настройка для сетевого интерфейса wlan0, который выходит в сеть Интернет.

dhcpcd.conf
# RaspAP default configurationhostnameclientidpersistentoption rapid_commitoption domain_name_servers, domain_name, domain_search, host_nameoption classless_static_routesoption ntp_serversrequire dhcp_server_identifierslaac privatenohook lookup-hostname# RaspAP wlan0 configurationinterface wlan0static ip_address=192.168.43.12/24static routers=192.168.43.1static domain_name_server=1.1.1.1 8.8.8.8


config.php портал конфигурации RaspAP

Файл настроек графического Web-интерфейса. Содержит переменные влияющие на отображение настроек. Самый главный параметр define('RASPI_WIFI_AP_INTERFACE', 'wlan1');. В качестве значения указать сетевой интерфейс hotspot wlan1.

config.php
...define('RASPI_WIFI_AP_INTERFACE', 'wlan1');...define('RASPI_ADBLOCK_ENABLED', true);define('RASPI_OPENVPN_ENABLED', false);...


Пошаговая установкаRaspAP


Руководство установки доступно в разделе Manual installation.

Шаг 1 Подключение адаптера USB WiFi RTL8188


Подключаем адаптер в любой доступный USB порт. В Armbian драйвера уже есть, поэтому проверим подключение командой lsusb:

root@bananapim64:~# lsusbBus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hubBus 003 Device 004: ID 0bda:c811 Realtek Semiconductor Corp.Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. HubBus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hubBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubroot@bananapim64:~#

В списке присутствует Realtek Semiconductor Corp., значит адаптер успешно распознался. Если вывести название интерфейса для подключенного адаптера, то его имя будет wlxe81e0584796d, что несколько далеко от привычного именования вида wlanX. Для задания названия для адаптера wlan1, необходимо выполнить следующие действия (более подробнее почитать про именование сетевых интерфейсов по ссылке1,ссылке2):

$ sudo ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules$ sudo reboot

После перезагрузки в системе будет два беспроводных адаптера: wlan0 и wlan1.

Шаг 2 Настройка сетевых интерфейсов


Настроим сетевые интерфейсы в конфигурационном файле: /etc/network/interfaces.

# Network is managed by Network managerauto loiface lo inet loopback# WANauto wlan0allow-hotplug wlan0iface wlan0 inet dhcp# Wi-Fi APauto wlan1iface wlan1 inet static    address 10.3.141.1    netmask 255.255.255.0    gateway 10.3.141.1

Шаг 3 Установка RaspAP


Теперь приступаем к установке RaspAP.
Обновление системы:

sudo apt-get updatesudo apt-get full-upgrade

Установка зависимостей для не RPi OS:

sudo apt-get install software-properties-common sudo add-apt-repository ppa:ondrej/phpsudo apt-get install dhcpcd5

Установка пакетов:

sudo apt-get install -y lighttpd git hostapd dnsmasq iptables-persistent vnstat qrencode php7.3-cgi

PHP:

sudo lighttpd-enable-mod fastcgi-php    sudo service lighttpd force-reloadsudo systemctl restart lighttpd.service

Создание Web-портала:

sudo rm -rf /var/www/htmlsudo git clone https://github.com/RaspAP/raspap-webgui /var/www/htmlWEBROOT="/var/www/html"CONFSRC="$WEBROOT/config/50-raspap-router.conf"LTROOT=$(grep "server.document-root" /etc/lighttpd/lighttpd.conf | awk -F '=' '{print $2}' | tr -d " \"")HTROOT=${WEBROOT/$LTROOT}HTROOT=$(echo "$HTROOT" | sed -e 's/\/$//')awk "{gsub(\"/REPLACE_ME\",\"$HTROOT\")}1" $CONFSRC > /tmp/50-raspap-router.confsudo cp /tmp/50-raspap-router.conf /etc/lighttpd/conf-available/sudo ln -s /etc/lighttpd/conf-available/50-raspap-router.conf /etc/lighttpd/conf-enabled/50-raspap-router.confsudo systemctl restart lighttpd.servicecd /var/www/htmlsudo cp installers/raspap.sudoers /etc/sudoers.d/090_raspap

Создание конфигурации:

sudo mkdir /etc/raspap/sudo mkdir /etc/raspap/backupssudo mkdir /etc/raspap/networkingsudo mkdir /etc/raspap/hostapdsudo mkdir /etc/raspap/lighttpdsudo cp raspap.php /etc/raspap 

Установка разрешения:

sudo chown -R www-data:www-data /var/www/htmlsudo chown -R www-data:www-data /etc/raspap

Настройка контролирующих скриптов:

sudo mv installers/*log.sh /etc/raspap/hostapd sudo mv installers/service*.sh /etc/raspap/hostapdsudo chown -c root:www-data /etc/raspap/hostapd/*.sh sudo chmod 750 /etc/raspap/hostapd/*.sh sudo cp installers/configport.sh /etc/raspap/lighttpdsudo chown -c root:www-data /etc/raspap/lighttpd/*.shsudo mv installers/raspapd.service /lib/systemd/systemsudo systemctl daemon-reloadsudo systemctl enable raspapd.service

Установка стартовых настроек, настройки в каталоге ~/temp, при необходимости заменить на свои:

sudo apt-get install -y curl unzipmkdir -p ~/tempcurl -SL --output ~/temp/config_ct.zip https://github.com/devdotnetorg/Site/raw/master/Uploads/files/config_ct.zipunzip ~/temp/config_ct.zip -d ~/temprm ~/temp/config_ct.zipесли есть: sudo mv /etc/default/hostapd ~/default_hostapd.oldесли есть: sudo cp /etc/hostapd/hostapd.conf ~/hostapd.conf.oldsudo cp ~/temp/default_hostapd /etc/default/hostapdsudo cp ~/temp/hostapd.conf /etc/hostapd/hostapd.confsudo cp config/090_raspap.conf /etc/dnsmasq.d/090_raspap.confsudo cp ~/temp/090_wlan1.conf /etc/dnsmasq.d/090_wlan1.confsudo cp ~/temp/dhcpcd.conf /etc/dhcpcd.confsudo cp ~/temp/config.php /var/www/html/includes/sudo cp ~/temp/defaults.json /etc/raspap/networking/sudo systemctl stop systemd-networkdsudo systemctl disable systemd-networkdsudo cp config/raspap-bridge-br0.netdev /etc/systemd/network/raspap-bridge-br0.netdevsudo cp config/raspap-br0-member-eth0.network /etc/systemd/network/raspap-br0-member-eth0.network 

Оптимизация PHP:

sudo sed -i -E 's/^session\.cookie_httponly\s*=\s*(0|([O|o]ff)|([F|f]alse)|([N|n]o))\s*$/session.cookie_httponly = 1/' /etc/php/7.3/cgi/php.inisudo sed -i -E 's/^;?opcache\.enable\s*=\s*(0|([O|o]ff)|([F|f]alse)|([N|n]o))\s*$/opcache.enable = 1/' /etc/php/7.3/cgi/php.inisudo phpenmod opcache

Настройка маршрутизации:

echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/90_raspap.conf > /dev/nullsudo sysctl -p /etc/sysctl.d/90_raspap.confsudo /etc/init.d/procps restartsudo iptables -t nat -A POSTROUTING -j MASQUERADEsudo iptables -t nat -A POSTROUTING -s 192.168.43.0/24 ! -d 192.168.43.0/24 -j MASQUERADEsudo iptables-save | sudo tee /etc/iptables/rules.v4

Включение hostapd:

sudo systemctl unmask hostapd.servicesudo systemctl enable hostapd.service

OpenVPN:

sudo apt-get install openvpnsudo sed -i "s/\('RASPI_OPENVPN_ENABLED', \)false/\1true/g" /var/www/html/includes/config.phpsudo systemctl enable openvpn-client@clientsudo mkdir /etc/raspap/openvpn/sudo cp installers/configauth.sh /etc/raspap/openvpn/sudo chown -c root:www-data /etc/raspap/openvpn/*.sh sudo chmod 750 /etc/raspap/openvpn/*.sh

Ad blocking:

sudo mkdir /etc/raspap/adblockwget https://raw.githubusercontent.com/notracking/hosts-blocklists/master/hostnames.txt -O /tmp/hostnames.txtwget https://raw.githubusercontent.com/notracking/hosts-blocklists/master/domains.txt -O /tmp/domains.txtsudo cp /tmp/hostnames.txt /etc/raspap/adblocksudo cp /tmp/domains.txt /etc/raspap/adblock sudo cp installers/update_blocklist.sh /etc/raspap/adblock/sudo chown -c root:www-data /etc/raspap/adblock/*.*sudo chmod 750 /etc/raspap/adblock/*.shsudo touch /etc/dnsmasq.d/090_adblock.confecho "conf-file=/etc/raspap/adblock/domains.txt" | sudo tee -a /etc/dnsmasq.d/090_adblock.conf > /dev/null echo "addn-hosts=/etc/raspap/adblock/hostnames.txt" | sudo tee -a /etc/dnsmasq.d/090_adblock.conf > /dev/nullsudo sed -i '/dhcp-option=6/d' /etc/dnsmasq.d/090_raspap.confsudo sed -i "s/\('RASPI_ADBLOCK_ENABLED', \)false/\1true/g" includes/config.php

При конфигурирование через Web-интерфейс столкнулся с багом, который при изменение настроек DHCP сервера на интерфейсе wlan1 удаляет файл конфигурации 090_wlan1.conf и не создает его заново. В результате DHCP сервер не выдает IP-конфигурацию новым клиентам. Временное решение этой проблемы заключается в блокировке файла на удаление, необходимо выполнить следующую команду (по блокировке файлов почитать по ссылке):

sudo chattr +i /etc/dnsmasq.d/090_wlan1.conf

После установки необходимо перезагрузить систему:

sudo reboot now

После перезагрузке появится Wi-Fi точка доступа с SSID raspi-webgui и паролем ChangeMe. Портал будет доступен по адресу: http://10.3.141.1.

Установка SoftEther VPN Server на VPS сервер


На сервер v636096.hosted-by-vdsina.ru установим Docker по официальному руководству Install Docker Engine on Ubuntu.

Создание сети для Docker контейнеров


Для подсети в которой будет контейнер с SoftEther VPN Server определим следующие параметры:

  • Название сети: vpnnetwork;
  • Subnet: 172.22.0.0/24;
  • Driver: bridge;
  • Range: 172.22.0.0/25;
  • gateway: 172.22.0.127;
  • HostMin: 172.22.0.1;
  • HostMax: 172.22.0.126;
  • Hosts/Net: 126.

Для создание внутренней сети Docker выполним команду:

$ docker network create --driver bridge --subnet 172.22.0.0/24 --ip-range=172.22.0.0/25 --gateway 172.22.0.127 vpnnetwork

Для проверки доступности сети выполнить команду: ping 172.22.0.127.

Создание контейнера с SoftEther VPN Server


Для создание контейнера будем использовать образ siomiz/softethervpn. До запуска основного контейнера необходимо создать конфигурацию, в которой указать пароль для управления сервером параметр SPW и пароль для управления хабом параметр HPW. Файл конфигурации будет располагаться по пути /usr/vpnserver/vpn_server.config. Выполнить следующие команды:

$ mkdir -p /usr/vpnserver$ docker run --name vpnconf -e "SPW={PASSWORD}" -e "HPW={PASSWORD}" siomiz/softethervpn echo$ docker cp vpnconf:/usr/vpnserver/vpn_server.config /usr/vpnserver/vpn_server.config$ docker rm vpnconf

Для уменьшения размера контейнера возьмем образ на основе Alpine, все журналы log в null. Выполнить следующие команды для создание контейнера:

$ docker run --name vps-server-softethervpn -d --cap-add NET_ADMIN --restart always --net vpnnetwork --ip 172.22.0.2 -p 443:443/tcp -p 992:992/tcp \-p 1194:1194/udp -p 5555:5555/tcp -v /usr/vpnserver/vpn_server.config:/usr/vpnserver/vpn_server.config \-v /dev/null:/usr/vpnserver/server_log -v /dev/null:/usr/vpnserver/packet_log -v /dev/null:/usr/vpnserver/security_log siomiz/softethervpn:alpine

Если контейнер запустился, то переходим к следующему шагу.

Настройка SoftEther VPN Server


Для настройки SoftEther VPN Server лучше использовать графическую утилиту для ОС Windows. Для загрузки необходимо перейти на страницу SoftEther Download Center. В списке Select Component, выбрать SoftEther VPN Server Manager for Windows, далее Select Platform windows. Можно выбрать пакет .zip без необходимости установки. Пакет softether-vpn_admin_tools-v4.34-9745-rtm-2020.04.05-win32.zip распаковать и запустить vpnsmgr.exe.

Создаем новый профиль кнопка New Setting, указываем следующие настройка:

  • Setting Name: VDSina_ru_main_server
  • Host Name: v636096.hosted-by-vdsina.ru
  • Port Number: 443
  • Password: пароль который был указан в переменной SPW при создание конфигурационного файла vpn_server.config

Затем подключаемся к серверу кнопка Connect.

При первом подключение появится вопрос об включение поддержки протокола IPSec. Если в дальнейшем планируете подключать мобильные устройства без использования программных клиентов, то выбрать Да. В данном случае поддержка IPSec не требуется, отвеваем Нет.

Для настройки алгоритма шифрования нажать на кнопку Encryption and Network. По умолчанию включен алгоритм DHE-RSA-AES256-SHA. Из списка выбрать другие более стойкие комбинации шифрования, но нужно помнить чем сильнее алгоритм, тем больше нагрузка на CPU сервера и на конечное маршрутизирующее устройство.

По умолчанию будет доступен хаб DEFAULT, удаляем его.

Создаем новый хаб кнопка Create a Virtual Hub. Укажем Virtual Hub Name: VPNROOT. Открываем настройки хаба кнопка Manage Virtual Hub.

Создадим пользователя подключения, кнопка Manage Users, затем кнопка New. Аутентификация будет по паре логин/пароль, укажем имя: officeuser1.

Для отделение подсети клиентов VPN сервера и подсети Docker контейнеров включим NAT, кнопка Virtual NAT and Virtual DHCP Server (SecureNAT), далее кнопка Enable SecureNAT. Изменим подсеть VPN клиентов на: 192.168.30.x, закроем окно, кнопка Exit.

На этом настройка сервера закончена.


Последовательность действий по настройке SoftEther VPN Server

Получение файлов конфигурации *.ovpn


Для подключения OpenVPN клиента необходимо получить файлы конфигурации *.ovpn, для этого переходим на главный экран настроек SoftEther VPN Server и нажимаем на кнопку OpenVPN / MS-SSTP Settings. Далее, в следующем окне генерируем файлы конфигурации, кнопка Generate a Sample Configuration File for OpenVPN Clients. Сохраняем архив OpenVPN_Sample_Config_v636096.hosted-by-vdsina.ru_20210519_150311.zip, для дальнейшего подключения потребуется файл f1167ecd086e_openvpn_remote_access_l3.ovpn.


Последовательность действий по получению файлов конфигурации *.ovpn

Настройка OpenVPN на RaspAP


Создание маршрутов
Теперь переходим в консоль Cubietruck и добавляем маршруты:

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEsudo iptables -A FORWARD -i tun0 -o wlan1 -m state --state RELATED,ESTABLISHED -j ACCEPTsudo iptables -A FORWARD -i wlan1 -o tun0 -j ACCEPT

Делаем копию существующих маршрутов и сохраняем новые

cp /etc/iptables/rules.v4 /etc/iptables/rules.v4.baksudo iptables-save | sudo tee /etc/iptables/rules.v4

Настройка профиля OpenVPN

Переходим на портал по адресу 192.168.43.12/openvpn_conf и указываем данные для подключения:

  • Username: officeuser1
  • Password: указанный для officeuser1 в SoftEther VPN Server
  • Для конфигурационного файла выбираем файл f1167ecd086e_openvpn_remote_access_l3.ovpn.

Сохраняем настройки и перезапускаем OpenVPN. Если подключение удалось, но в поле IPV4 ADDRESS будет публичный IP-адрес VPN сервера: 94.103.85.152 (v636096.hosted-by-vdsina.ru).

raspap
Страница настроек OpenVPN в RaspAP

Настройка Captive portal


Установка Captive portal в руководстве Captive portal setup.

Для установки выполним следующие действия:

sudo apt-get updatesudo apt-get install -y libmicrohttpd-devcd ~/git clone https://github.com/nodogsplash/nodogsplash.gitcd nodogsplashmakesudo make install

Далее необходимо внести изменения в конфигурационный файл /etc/nodogsplash/nodogsplash.conf. Указать следующие параметры:

...GatewayInterface wlan1...GatewayAddress 10.3.141.1...

Регистрация службы и запуск:

sudo cp ~/nodogsplash/debian/nodogsplash.service /lib/systemd/system/sudo systemctl enable nodogsplash.servicesudo systemctl start nodogsplash.service sudo systemctl status nodogsplash.service

Страницы html для изменение дизайна страниц располагаются по пути: /etc/nodogsplash/htdocs/. Теперь выполним подключение к AP SSID: raspi-webgui.

Устранение проблем


Первым делом необходимо проверить IP-конфигурацию сетевых интерфейсов, командами: ifconfig или ip a.

Проверить занятость портов, командами:

netstat -ntlp | grep LISTENlsof -i | grep LISTENlsof -nP -i | grep LISTEN

Если установка RaspAP выполняется на Ubuntu, то вы можете столкнуться с конфликтом использования 53 порта, который занят службой systemd-resolved. Для отключения данной службы, воспользоваться материалом How to disable systemd-resolved in Ubuntu.

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

sudo systemctl status hostapd.servicesudo systemctl status dnsmasq.servicesudo systemctl status lighttpd.servicesudo systemctl status openvpn-client@clientsudo systemctl status nodogsplash.servicesudo systemctl status raspapd.service


Что дальше?


Для проверки совместимости необходимо RaspAP развернуть на Banana Pi BPI-M64 (Armbian 21.02.1 на основе Ubuntu 18.04.5 LTS). Далее, развернуть на x86 с другим более новым адаптером, например USB Realtek 8811CU Wireless LAN 802.11ac. На GitHub размещен репозиторий raspap-docker, который оборачивает RaspAP в контейнер, но по факту запускает скрипт автоматической установки, что несколько неудобно и неправильно. Поэтому для более широкого распространения RaspAP необходимо его правильно обернуть в Docker контейнер для ARM и x86 архитектур.

Итог


Проект RaspAP безусловно заслуживает внимания, основные функции работают отлично. Это единственный проект связанный с Wi-Fi сетями, работающий поверх существующей ОС, у которого работает Web-интерфейс (пока есть небольшие баги). Для личного использования, теста, стоит попробовать. Но для продакшен в бизнесе пока лучше не использовать, необходимо более детально просмотреть исходный код и конфигурацию на предмет безопасности. В любом случае, проект добавил себе в закладки, надеюсь баги исправят в скором времени.



На правах рекламы


VDSina предлагает виртуальные серверы на Linux и Windows выбирайте одну из предустановленных ОС, либо устанавливайте из своего образа.

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

Нагрузочное тестирование СХД на Эльбрусе на базе нового ядра Линукс версии 5.4

31.05.2021 06:09:55 | Автор: admin


Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.


По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.


Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.


В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:


Общие обновления:


  • переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
  • много мелких оптимизаций под скоростные твердотельные накопители;
  • и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:


  • обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
  • обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд


Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16G 1 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.



Методика тестирования


Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).


СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).


Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.


В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:


Последовательная нагрузка маленькими блоками 4k


  • 100%_read_4k_sequential
  • 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k


  • 100%_read_4k_random
  • 100%_write_4k_random

Последовательная нагрузка большими блоками 128k


  • 100%_read_128k_sequential
  • 100%_write_128k_sequential

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


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


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


100%_read_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/read-iodepth-128-numjobs-16
write_iops_log=./logs/read-iodepth-128-numjobs-16
write_lat_log=./logs/read-iodepth-128-numjobs-16
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=write
numjobs=16
runtime=2400
time_based=1


write_bw_log=./logs/4k-seq-write.results


write_iops_log=./logs/4k-seq-write.results


write_lat_log=./logs/4k-seq-write.results


[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_read_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=64
group_reporting
rw=randread
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-read.results
write_iops_log=./logs/4k-rand-read.results
write_lat_log=./logs/4k-rand-read.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_write_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=randwrite
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-write.results
write_iops_log=./logs/4k-rand-write.results
write_lat_log=./logs/4k-rand-write.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_read_128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-read.results
write_iops_log=./logs/128k-seq-read.results
write_lat_log=./logs/128k-seq-read.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=write
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-write.results
write_iops_log=./logs/128k-seq-write.results
write_lat_log=./logs/128k-seq-write.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]


Результаты тестов


Последовательная нагрузка маленькими блоками 4k


100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.


Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.


Случайная нагрузка маленькими блоками 4k


100%_read_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.


Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.


Также с прошлого ядра сохранилась приятная особенность. Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать.


Последовательная нагрузка большими блоками 128k


100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).


При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).


А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).


Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4


Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые


Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19


Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые


Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.


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


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


Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.


В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).


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


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

Подробнее..

Почему клавиатура всегда быстрее мыши

27.05.2021 10:19:54 | Автор: admin

Тепловая карта с клавиатуры высокоинтеллектуальных программистов, источник: r/ProgrammerHumor/

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

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

В чём же дело?

Экзотический манипулятор


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

Необычные манипуляторы с колёсиком стоили в районе 400 долларов. Затем вышел революционный компьютер Apple Lisa один из первых ПК с графическим интерфейсом. Компания Apple демпинговала она снизила стоимость манипулятора до 25 долларов и сделала сексуальный дизайн с одной кнопкой. Мышь из профессионального аксессуара превратилась в массовый гаджет.


Apple Lisa. Очень элегантный дизайн для своего времени

С тех пор мышь и GUI стали прочно ассоциироваться с компьютерами Apple и модным оконным интерфейсом.

Вскоре появилась Windows. Затем первые игры с поддержкой мыши, например, для более точного движения персонажа Возникает впечатление, что компьютерные игры постоянно стимулировали технический прогресс, в том числе производительность CPU, GPU, ёмкость накопителей, популярность мышей и других экзотических манипуляторов.

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

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

В наше время редко встретишь компьютер без мыши. А вот удовольствие от работы в консоли осталось.

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

Крутые однострочники


Вот некоторые примеры интересного использования программ Linux.

ps aux | convert label:@- process.png

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

Примечание. Утилита convert входит в пакет ImageMagick, так что нужно сначала его установить.

А вообще, текст из консоли можно быстро запостить через интернет-сервис вроде termbin.com (это как pastebin, только для консоли):

ps aux | nc termbin.com 9999

Как обычно, с алиасом для частого использования:

alias tb='nc termbin.com 9999'

Следующая:

curl ipinfo.io

Это если хотите узнать свой внешний IP-адрес через сервис ipinfo.io.

git log --format='%aN' | sort -u

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

history | awk '{print $2}' | sort | uniq -c | sort -rn | head

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

ls -d */

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

du -hs */ | sort -hr | head

Эта команда показывает только 10 крупнейших директорий в текущем каталоге.

ss -p

Просмотр, какие приложения потребляют трафик (утилиты iftop и nethogs дают более подробную информацию).

rm -f !(test.txt)

Команда удаляет из директории все файлы, кроме одного, указанного в скобках. Это работает после включения расширенной глобуляции в баше (shopt -s extglob).

python3 -m http.server

Запускает http-сервер и начинает отдавать файлы. Удобно, если хотите пошарить какой-то html-файл по сети.

screen -S the-screen-name

Создание экран-сессии.

screen -x the-screen-name

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

Утилита screen поставляется по умолчанию со многими дистрибутивами Linux, хотя не со всеми.

alias copy='xclip -i -selection clipboard'

cat file.txt | copy

Копирование файла в буфер обмена, когда первый однострочник прописан как алиас copy в баше.

sudo !!

Запустить последнюю команду под рутом, если в предыдущей команде вы забыли набрать sudo. У этой команды первое место в рейтинге однострочников.

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

Горячие клавиши как наследие консоли


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

Алиасы bash служат той же цели: выполнить команду с наименьшим количеством усилий, то есть с наименьшим количеством нажатий клавиш.

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

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

Это фундаментальное преимущество клавиатуры как инструмента для ввода команд по сравнению с любыми манипуляторами. В этом же и сила консоли.

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

В общем, из этого факта может родиться предположение, что отцы-основатели Unix всё-таки были правы, а их наследие живёт во всех операционных системах. Графическая оболочка просто тонкий слой абстракции поверх мощного фундамента, который они построили. Ведь мы помним, что macOS тоже основана на Unix и относится к семейству *nix-систем.

Ну а окошки и другие элементы графического интерфейса Windows, по мнению Apple, это вторичный продукт, скопированный с интерфейса Lisa (см. судебный процесс Apple против Microsoft c 1988 по 1994 гг).

Суд отклонил иск Apple к Microsoft. Но некоторые вещи обращают на себя внимание. Например, команда open . в консоли macOS открывает Finder в текущей директории. В Windows то же самое делает команда start . (Finder здесь называется Explorer). Окна в macOS закрываются крестиком в левом верхнем углу, а в Windows в правом углу. Возможно, на примере таких деталей Билл Гейтс доказал суду, что у него оригинальный графический интерфейс, который сильно отличается от macOS.

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



На правах рекламы


Наша компания предлагает аренду VPS для совершенно любых проектов. Создайте собственный тарифный план в пару кликов, максимальная конфигурация позволит разместить практически любой проект 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

FOSS News 72 дайджест материалов о свободном и открытом ПО за 2430 мая 2021 года

30.05.2021 20:12:29 | Автор: admin

Всем привет!


Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире.


Главные темы нового выпуска:


  1. Google начал установку ОС Fuchsia на устройства Nest Hub.
  2. Microsoft, GitHub, Accenture и ThoughtWorks при поддержке Linux Foundation основали Фонд экологичного ПО.
  3. Открыт код сервиса проверки паролей HaveIBeenPwned.
  4. Соглашение о долгосрочном сотрудничестве: Карачаево-Черкесская Республика внедряет ОС Альт.
  5. Базальт СПО приглашает на объединенную конференцию СПО: от обучения до разработки.
  6. Второе интервью с разработчиком Reiser4 Эдуардом Шишкиным.
  7. Пользователь получил предупреждение от провайдера за скачивание Ubuntu.
  8. Я нашёл лучший линукс (мнение популярного блоггера).

И многое другое



Оглавление


  1. Главное
    1. Google начал установку ОС Fuchsia на устройства Nest Hub
    2. Microsoft, GitHub, Accenture и ThoughtWorks при поддержке Linux Foundation основали Фонд экологичного ПО
    3. Открыт код сервиса проверки паролей HaveIBeenPwned
    4. Соглашение о долгосрочном сотрудничестве: Карачаево-Черкесская Республика внедряет ОС Альт
    5. Базальт СПО приглашает на объединенную конференцию СПО: от обучения до разработки
    6. Второе интервью с разработчиком Reiser4 Эдуардом Шишкиным
    7. Пользователь получил предупреждение от провайдера за скачивание Ubuntu
    8. Я нашёл лучший линукс
  2. Короткой строкой
    1. Новости
      1. Мероприятия
      2. Внедрения
      3. Открытие кода и данных
      4. Дела организаций
      5. Ядро и дистрибутивы
      6. Обучение
      7. Базы данных
      8. Мобильные
      9. Безопасность
      10. DevOps
      11. Web
      12. Пользовательское
    2. Статьи
      1. Внедрения
      2. Дела организаций
      3. DIY
      4. Ядро и дистрибутивы
      5. Системное
      6. Специальное
      7. Базы данных
      8. Мультимедиа
      9. Безопасность
      10. DevOps
      11. AI & Data Science
      12. Web
      13. Для разработчиков
      14. Пользовательское
      15. Разное
    3. Релизы
      1. Ядро и дистрибутивы
      2. Системное
      3. Специальное
      4. Базы данных
      5. Мультимедиа
      6. DevOps
      7. AI & Data Science
      8. Web
      9. Для разработчиков
      10. Пользовательское
  3. Что ещё посмотреть
  4. Заключение

Главное


Google начал установку ОС Fuchsia на устройства Nest Hub


Категория: Новости/Внедрения

OpenNET пишет: Петр Хосек (Petr Hosek), возглавляющий в Google команду, отвечающую за системы сборки, компиляторы и инструментарий для разработчиков, представил первое устройство, которое будет комплектоваться операционной системой Fuchsia. Прошивка на базе Fuchsia начнёт доставляться в умные рамки для фотографий Nest Hub в рамках экспериментального обновления для участников программы Google Preview Program. Если в ходе пробного внедрения не возникнет непредвиденных проблем, прошивка на базе Fuchsia будет применена и на устройства остальных пользователей Nest Hub, которые не заметят отличий так как интерфейс, построенный на базе фреймворка Flutter, останется прежним, изменятся только низкоуровневые составляющие операционной системы. Ранее в выпускаемых с 2018 года устройствах Google Nest Hub, сочетающих функции рамки для фотографий, мультимедийной системы и интерфейса для управления умным домом, применялась прошивка на базе оболочки Cast и ядра Linux. Напомним, что в рамках проекта Fuchsia компанией Google c 2016 года развивается универсальная операционная система, способная работать на любых типах устройств, от рабочих станций и смартфонов до встраиваемой и потребительской техники. Разработка ведётся с учётом опыта создания платформы Android и учитывает недостатки в области масштабирования и обеспечения безопасности.


Подробности:


  1. Google начал установку ОС Fuchsia на устройства Nest Hub []
  2. Fuchsia OS от Google дебютирует на Nest Hub [(en)]
  3. Google запускает свою третью по величине операционную систему Fuchsia[(en)]
  4. Операционная система Google Fuchsia начинает раннее развертывание на потребительских устройствах [(en)]
  5. Google запускает ОС Fuchsia []
  6. Google официально представил свою третью ОС подробнее о Fuchsia []
  7. Официальный выпуск Fuchsia OS 1.0 []
  8. ОС Fuchsia от Google теперь работает на Nest Hub первого поколения[(en)]

Подробности []


Microsoft, GitHub, Accenture и ThoughtWorks при поддержке Linux Foundation основали Фонд экологичного ПО


Категория: Новости/Дела организаций

Пользователь denis-19 опубликовал в новостях на Хабре: 25 мая Microsoft, GitHub, Accenture и ThoughtWorks при поддержке Linux Foundation объявили об основании некоммерческой организации Фонда экологичного ПО (Green Software Foundation). В планах Фонда добиться сокращения выбросов парниковых газов IT-компаниями на 45% к 2030 году в соответствии с Парижским соглашением по климату путём уменьшения с помощью свободного ПО энергопотребления в центрах обработки данных (ЦОД) по всему миру. Цель Фонда создание надёжной экосистемы, объединяющей лучшие практики, стандарты, инструменты и специалистов, для стимулирования устойчивого развития индустрии разработки свободного программного обеспечения.


Подробности:


  1. Microsoft, GitHub, Accenture и ThoughtWorks при поддержке Linux Foundation основали Фонд экологичного ПО []
  2. Linux Foundation вместе с Accenture, GitHub, Microsoft и ThoughtWorks запускает фонд Green Software Foundation, который ставит экологическую устойчивость в основу разработки программного обеспечения.[(en)]

Открыт код сервиса проверки паролей HaveIBeenPwned


Категория: Новости/Открытие кода и данных

OpenNET пишет: Трой Хант (Troy Hunt) открыл исходные тексты сервиса проверки скомпрометированных паролей Have I Been Pwned? (haveibeenpwned.com), выполняющего проверку по базе в 11,2 миллиардах учётных записей, похищенных в результате взломов 538 сайтов. Изначально о намерении открыть код проекта было объявлено в августе прошлого года, но процесс затянулся и код опубликован только сейчас. Код сервиса написан на C# и опубликован под лицензией BSD. Проект планируется развивать с привлечением сообщества под покровительством некоммерческой организации .NET Foundation.


Подробности:


  1. Открыт код сервиса проверки паролей HaveIBeenPwned []
  2. Have I Been Pwned становится открытым исходным кодом и объединяется с ФБР в борьбе с утечкой паролей [(en)]
  3. Сервис проверки утечек паролей Have I Been Pwned выходит с открытым исходным кодом [(en)]
  4. Have I Been Pwned теперь Open Source [(en)]

Соглашение о долгосрочном сотрудничестве: Карачаево-Черкесская Республика внедряет ОС Альт


Категория: Новости/Внедрения

Базальт СПО пишет: Компания Базальт СПО и Министерство цифрового развития Карачаево-Черкесской Республики заключили соглашение о долгосрочном комплексном сотрудничестве. Цель сформировать технологически независимую цифровую среду экономики и социальной сферы региона. Первые проекты миграции на отечественные программные продукты стартуют в Карачаево-Черкесии в 2021 году. На российские операционные системы Альт и прикладное программное обеспечение переведут свою цифровую инфраструктуру учебные заведения республики. По заявкам школ и организаций дошкольного образования Базальт СПО будет предоставлять им льготные лицензии на ОС Альт.


Подробности []


Базальт СПО приглашает на объединенную конференцию СПО: от обучения до разработки


Категория: Новости/Мероприятия

Базальт СПО пишет: Приглашаем разработчиков российского свободного программного обеспечения, преподавателей и студентов на конференцию СПО: от обучения до разработки, которая пройдет 1518 июня 2021 г. в Переславле-Залесском. Конференция объединит два традиционных ежегодных мероприятия Базальт СПО: конференцию разработчиков свободных программ и конференцию СПО в высшей школе. На дискуссионных площадках встретятся ведущие разработчики СПО из России и стран ближнего зарубежья, педагоги вузов и школ, которые уже используют свободные программы для проведения занятий, студенты и школьники, которые стремятся стать профессионалами в разработке СПО.


Подробности []


Второе интервью с разработчиком Reiser4 Эдуардом Шишкиным


Категория: Статьи/Системное

На Хабре вышло интервью с разработчиком файловой системы Reiser4 Эдуардом Шишкиным. Были обсуждены:


  1. вопросы организации разработки ядра Linux;
  2. плюсы и минусы разных файловых систем;
  3. принципы построения локальных и сетевых файловых систем;
  4. новости разработки Reiser4.

Подробности []


Пользователь получил предупреждение от провайдера за скачивание Ubuntu


Категория: Новости/Юридические вопросы

denis-19 пишет в новостях на Хабре: 26 мая 2021 года пользователь Reddit под ником NateNate60 рассказал, что получил от своего интернет-провайдера Comcast уведомление о том, что он недавно скачал через торрент ISO-образ ОС Ubuntu (ubuntu-20.04.2.0-desktop-amd64.iso) и тем самым нарушил закон об авторском праве. Провайдер попросил пользователя выполнить поиск этого пиратского контента на всех своих устройствах, подключенных к его сети, и удалить файлы, упомянутые в уведомлении. Контент, предположительно нарушающий авторские права, это 64-битная версия ОС Ubuntu 20.04.2.0 LTS. Примечательно, что в уведомлении указано хеш-значение 4ba4fbf7231a3a660e86892707d25c135533a16a, которое соответствует хешу официального выпуска этой редакции дистрибутива Ubuntu от Canonical. В Canonical заинтересовались этой проблемой и изучают её причину.


Подробности [ 1, 2(en)]


Я нашёл лучший линукс


Категория: Статьи/Пользовательское

Популярный GNU/Linux видеоблогер PLAFON опубликовал новое видео, где поделился своим выбором нового GNU/Linux дистрибутива после того, как долгое время использовал Arch-подобные. Выбор делался с точки зрения новизны поставляемого ПО, качества системы, сообщества и других факторов.


Подробности []


Короткой строкой


Новости


Мероприятия


На конференции IT-Community в Иркутске Базальт СПО познакомил сибиряков с ОС Альт и заключил соглашения о сотрудничестве []


Внедрения


CloudLinux предоставляет услуги поддержки Linux для Министерства обороны США[(en)]


Открытие кода и данных


Golos самый большой русскоязычный речевой датасет, размеченный вручную, теперь в открытом доступе []


Дела организаций


  1. Стартап Airbyte, разрабатывающий конвейер данных с открытым исходным кодом, привлекает 26 миллионов долларов[ 1(en), 2(en), 3(en)]
  2. Инцидент с потерей контроля над каналами в IRC-сети FreeNode [ 1, 2(en)]
  3. Более 80 разработчиков Linux помогалиисправить беспорядок, созданный вредоносными действиями разработчиков Университета Миннесоты [(en)]
  4. Инвесторы Da Vinci Capital подали иск против Telegram []
  5. Прекращение разработки Glimpse, форка графического редактора GIMP []
  6. Orbit получил $15 млн на устранение хаоса данных сообщества[(en)]
  7. Mirantis делает ставку на упрощение работы разработчиков с Kubernetes [(en)]
  8. Puppet назначает Бет Ши на должность директора по работе с клиентами [(en)]
  9. SUSE создаёт новое сообщество для пользователей Rancher и SUSE [(en)]
  10. AWS надеется на расширение партнёрства с Docker по мере роста количества контейнеров [(en)]
  11. Еженедельник OSM 565 []

Ядро и дистрибутивы


  1. Microsoft делает общедоступной поддержку приложений Linux с графическим интерфейсом в Windows 10 [ 1(en), 2(en)]
  2. Универсальный базовый образ Red Hat теперь доступен в Docker Hub [(en)]

Обучение


Книга PowerShell для сисадминов []


Базы данных


Что нового в плане мониторинга в PostgreSQL 14 []


Мобильные


  1. Альтернатива Huawei HarmonyOS для Android должна выйти 2 июня[ 1(en), 2(en)]
  2. Грядут изменения конфиденциальности Android вы готовы? [(en)]

Безопасность


  1. Почтовый клиент Mozilla Thunderbird мог быть использован для компрометации отправителя[(en)]
  2. Accurics стремится снизить затраты на безопасность с помощью политики как кода для устранения уязвимости Kubernetes [(en)]

DevOps


  1. UXP это новый открытый дистрибутив корпоративного уровня для Crossplane CNCF[(en)]
  2. New Relic улучшает наблюдаемость Kubernetes с помощью программного обеспечения Pixie с открытым исходным кодом [(en)]
  3. Docker запускает программу Verified Publisher для повышения безопасности контейнеров для разработчиков [(en)]
  4. Docker представляет новые возможности для разработчиков на DockerCon Live [(en)]
  5. По данным Docker, разработчики всё больше осознают потенциал контейнеризации [(en)]
  6. Результаты тестирования Service Mesh: Linkerd превосходит Istio [(en)]

Web


  1. Google выпустила исправления для Chrome после сбоев на Windows 10 и Linux [ 1, 2(en)]
  2. Mozilla обобщила планы по поддержке в Firefox третьей версии манифеста Chrome [ 1, 2(en)]
  3. Google подробно описывает технологию оптимизации кода, которая лежит в основе последнего повышения скорости Chrome на 23% [ 1(en), 2(en)]
  4. Mozilla подготовила для Firefox дополнение с системой машинного перевода []
  5. Браузер Google Chrome теперь насчитывает более 3 миллиардов пользователей[(en)]
  6. Последние обновления Google Chrome и Chrome OS предлагает несколько отличных новых функций особенно для пользователей Linux[(en)]
  7. Развитие проекта arataga: пара рефакторингов по результатам натурных испытаний []
  8. В обновлении Google Chrome добавлена командная строка [(en)]
  9. Протокол QUIC получил статус предложенного стандарта []

Пользовательское


На этой неделе в KDE: тестирование Plasma 5.22! []


Статьи


Внедрения


Как Linux подготовил школу к пандемии[(en)]


Дела организаций


Партнерство Docker и Snyk нацелено на безопасность[(en)]


DIY


Часть 3: Продолжаем пилить мультигаджет ESPboy2 для ретро игр и экспериментов с IoT в 2021 []


Ядро и дистрибутивы


Внутренности Linux: как /proc/self/mem пишет в недоступную для записи память []


Системное


Что такое демоны в Linux [ 1, 2(en)]


Специальное


  1. Как установить и использовать XRDP в Ubuntu для подключения к удалённому рабочему столу[(en)]
  2. Легенды и мифы геофизики []
  3. Установка Proxmox в Debian 10 []
  4. О контроле теплицы с помощью CircuitPython и инструментов с открытым исходным кодом[(en)]
  5. 6 новых интересных функций ShellHub, на которые стоит обратить внимание в 2021 году [(en)]
  6. Clustergram: визуализация кластерного анализа на Python []
  7. Полное руководство по настройке SSH в Ubuntu[(en)]

Базы данных


pgSCV экспортер метрик для PostgreSQL []


Мультимедиа


  1. Видео: Краткая история Blender. Отчет Blender Foundation []
  2. Одна коллекция плагинов Inkscape, чтобы править ими всеми[(en)]

Безопасность


  1. Тестирование на проникновение с помощью инструментов безопасности Linux[(en)]
  2. SPDX уже используется для Global Software Bill of Materials (SBOM) и безопасности цепочки поставок [(en)]
  3. Насколько безопасны повторно используемые компоненты Kubernetes [(en)]
  4. Найти и не обезвредить: пишем пентесты с Kali Linux []

DevOps


  1. Инструмент с открытым исходным кодом Yor проводит автоматический аудит IaC[ 1(en), 2(en)]
  2. Service Mesh Wars, прощаемся с Istio []
  3. Мониторинг 95+ метрик PostgreSQL с помощью плагина Zabbix Agent 2 []
  4. Kubernetes-in-Kubernetes и ферма серверов с загрузкой по PXE []
  5. Лучшие практики для безопасности Kubernetes[(en)]
  6. Бэкапы для HashiCorp Vault с разными бэкендами []
  7. Сеть контейнеров это не сложно []
  8. Ход конём: как принимать сообщения в Kafka через Nginx []
  9. Kubernetes изучаем паттерн Sidecar []
  10. Как Kubernetes изменит Cloud Foundry[(en)]

AI & Data Science


  1. Руководство для начинающих по логистической регрессии в Python[(en)]
  2. Руководство для начинающих по линейной регрессии в Python [(en)]
  3. Как адаптировать языковые модели Kaldi? (со смешными животными) []
  4. Как TensorFlow Lite вписывается в экосистему TinyML[(en)]
  5. Начало работы с созданием изображений с помощью TensorFlow Keras [(en)]
  6. Начало работы с анализом настроений с использованием TensorFlow Keras [(en)]
  7. Язык определения интентов NlpCraft IDL []
  8. Полное руководство Python по глубокой несбалансированной регрессии[(en)]

Web


Становится ли Telegram новой альтернативой Dark Web?[(en)]


Для разработчиков


  1. 3 причины изучить Java в 2021 году[(en)]
  2. 4 шага для настройки глобальных модалов в React [(en)]
  3. Полное руководство по рекурсии и итерации в Python [(en)]
  4. Обработка модульных и динамических файлов конфигурации в командной оболочке [(en)]
  5. О переносе операционных систем на новые архитектуры микросхем [(en)]
  6. Что нужно знать о Quarkus в 2021 году [(en)]

Пользовательское


  1. Gromit-MPX позволяет рисовать где угодно на экране рабочего стола Linux[(en)]
  2. Следите за характеристиками вашего компьютера Linux с помощью KInfoCenter [(en)]
  3. Запуск Flatpak из терминала [(en)]
  4. Осторожно, snap []
  5. Трюки в консоли. Крутые однострочники []
  6. Как настроить KDE Plasma []

Разное


  1. Что представляет собой офис по работе с открытым исходным кодом?[(en)]
  2. Генеральный директор Percona говорит об открытом исходном коде в эпоху облачных технологий [(en)]
  3. Семейная история использования Linux [(en)]

Релизы


Ядро и дистрибутивы


  1. Вышел Floppinux 0.1.0 дистрибутив Linux, умещающийся на одной 3,5-дюймовой дискете [ 1, 2, 3, 4(en), 5]
  2. Выпуск antiX 19.4, дистрибутива для устаревшего оборудования [ 1, 2]
  3. Новая версия Simply Linux 9.1 [ 1, 2, 3, 4]
  4. Опубликован AV Linux 2021.05.22, дистрибутив для создания аудио- и видеоконтента []
  5. Представлен полностью свободный Linux-дистрибутив PureOS 10 []
  6. Выпуск дистрибутива OSGeo-Live 14.0 с подборкой геоинформационных систем []
  7. Доступен дистрибутив AlmaLinux 8.4, продолжающий развитие CentOS 8 []
  8. Выпуск дистрибутива Oracle Linux 8.4 []
  9. Компания Virtuozzo опубликовала дистрибутив VzLinux, нацеленный на замену CentOS 8 []

Системное


  1. Второй выпуск Libreboot, полностью свободного дистрибутива Coreboot []
  2. Выпуск пакетного фильтра nftables 0.9.9 []
  3. Выпуски пакетного менеджера Pacman 6.0 и инсталлятора Archinstall 2.2.0 []
  4. Microsoft выпустила пакетный менеджер Windows Package Manager 1.0, похожий на apt и dnf []

Специальное


Выпуск Wine версии 6.9 []


Базы данных


  1. Databricks представляет Delta Sharing, инструмент с открытым исходным кодом для обмена данными[ 1(en), 2(en)]
  2. Опубликована СУБД immudb 1.0, обеспечивающая защиту от искажения данных []

Мультимедиа


  1. Выпуск музыкального проигрывателя Qmmp 1.5.0 [ 1, 2, 3]
  2. Выпуск редактора векторной графики Inkscape 1.1 [ 1, 2]
  3. Релиз программы для записи и обработки звука Ardour 6.7 []

DevOps


  1. Polaris 4.0 включает поддержку всех ресурсов Kubernetes[(en)]
  2. Команда Kali Linux выпускает Kaboxer, инструмент для управления приложениями в контейнерах [(en)]
  3. Представляем OpenShift Pipelines []
  4. KubeSphere 3.1.0: предоставление командам DevOps возможности запускать приложения в Kubernetes где угодно и когда угодно[(en)]

AI & Data Science


  1. KotlinDL 0.2: Functional API, зоопарк моделей c ResNet и MobileNet, DSL для обработки изображений []
  2. Microsoft выпускает Power BI для блокнотов Jupyter[(en)]

Web


  1. Выпуски nginx 1.21.0 и nginx 1.20.1 с устранением уязвимости []
  2. Релиз Chrome 91 []

Для разработчиков


  1. Состоялся выпуск FPC 3.2.2! []
  2. QtProtobuf 0.6.0 []

Пользовательское


  1. Альфа-выпуск LibreOffice 7.2 []
  2. Выпуск online-редакторов ONLYOFFICE Docs 6.3 []

Что ещё посмотреть


Open-source проект недели по версии SD Times: Ugly Duckling [(en)]


Заключение


На этом всё, до следующего воскресенья!


Подписывайтесь на наш Telegram канал наш Telegram канал или RSS чтобы не пропустить новые выпуски FOSS News. Также мы есть во всех основных соцсетях:


  1. Fediverse []
  2. ВКонтакте []
  3. Facebook []
  4. Twitter []

[] Предыдущий выпуск





Если кто интересуется составлением дайджестов и имеет время и возможность помочь буду рад, пишите по контактам, указанным в моём профиле, или в личные сообщения. В первую очередь нужны люди, готовые помогать в разборе материалов, собранных роботом по нескольким десяткам англо- и русскоязычных источников, а именно разработчики, которые хотели бы поучаствовать в доработке средств автоматизации под многопользовательский режим (скорее всего это будет в форме Telegram чат-бота на Python), и просто активисты, которые смогли бы тратить несколько часов в неделю на работу с будущим автоматизированным категоризатором (записываться уже можно, уведомим по готовности инструмента). Подробнее о внутренней кухне дайджестов можно прочитать в спецвыпуске FOSS News [].






Думаю, все в курсе сложной ситуации, в которой оказался FSF (Фонд Свободного ПО) из-за конфликта вокруг его основателя Ричарда Столлмана. Подробности можно посмотреть в наших подборках новостей [ 1, 2]. Я считаю, что самое время поддержать Фонд вступлением и финансами []. FSF это одна из немногих организаций, бескомпромиссно стоящих на защите интересов большинства людей, использующих компьютеры в работе, общественной активности и для личных дел. А чтобы организация полностью работала в интересах людей, она должна этими людьми и финансироваться. К слову, 80% финансирования FSF идёт от частных лиц.

Подробнее..

FOSS News 73 дайджест материалов о свободном и открытом ПО за 31 мая 6 июня 2021 года

06.06.2021 22:21:53 | Автор: admin

Всем привет!


Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире.


Главные темы нового выпуска:


  1. Huawei представила первые мобильные устройства на HarmonyOS 2.0 и объявила о замене Android на HarmonyOS на своих смартфонах.
  2. Результаты исследования об условиях труда Open Source мейнтейнеров.
  3. Роснефть передала ноутбуки с ОС Astra Linux многодетным семьям.
  4. NocoDB, open-source аналог Airtable.
  5. Интервью с Дэниелом Скейлсом, главным юрисконсультом по бренду в Linux Foundation.
  6. Google представил сервис для наглядного отслеживания зависимостей.
  7. История графической оболочки GNOME.

И многое другое



Оглавление


  1. Главное
    1. Huawei представила первые мобильные устройства на HarmonyOS 2.0 и объявила о замене Android на HarmonyOS на своих смартфонах
    2. Результаты исследования об условиях труда Open Source мейнтейнеров
    3. Роснефть передала ноутбуки с ОС Astra Linux многодетным семьям
    4. NocoDB, open-source аналог Airtable
    5. Интервью с Дэниелом Скейлсом, главным юрисконсультом по бренду в Linux Foundation
    6. Google представил сервис для наглядного отслеживания зависимостей
    7. История графической оболочки GNOME
  2. Короткой строкой
    1. Новости
      1. Мероприятия
      2. Внедрения
      3. Открытие кода и данных
      4. Дела организаций
      5. Ядро и дистрибутивы
      6. Системное
      7. Обучение
      8. Безопасность
      9. AI & Data Science
      10. Web
      11. Пользовательское
      12. Игры
    2. Статьи
      1. DIY
      2. Ядро и дистрибутивы
      3. Системное
      4. Специальное
      5. Базы данных
      6. Безопасность
      7. DevOps
      8. AI & Data Science
      9. Web
      10. Для разработчиков
      11. Пользовательское
      12. Игры
      13. Железо
      14. Разное
    3. Релизы
      1. Ядро и дистрибутивы
      2. Системное
      3. Специальное
      4. Базы данных
      5. Мультимедиа
      6. Web
      7. Для разработчиков
      8. Пользовательское
      9. Игры
  3. Что ещё посмотреть
  4. Заключение

Главное


Huawei представила первые мобильные устройства на HarmonyOS 2.0 и объявила о замене Android на HarmonyOS на своих смартфонах


Категория: Релизы/Мобильные

Travis_Macrif пишет в новостях на Хабре: Китайская компания Huawei анонсировала линейку мобильных устройств, которые первыми будут работать на операционной системе HarmonyOS 2.0. Среди представленных гаджетов планшеты: 10.8 и 12.6-дюймовые MatePad Pro, MatePad 11; смартфоны: Mate40 Pro, Mate X2, Mate40E и nova 8 Pro; смарт-часы: Watch 3 и Watch 3 Pro. Производитель также заявил, что в скором времени представит перечень устройств Huawei, которые будет возможно перевести с Android на HarmonyOS. Все устройства работают на HarmonyOS 2.0. Операционная система является форком Android, использует ядро Linux и имеет открытый исходный код от AOSP. Huawei отметила, что более 100 моделей гаджетов компании, которые в настоящий момент функционируют на Android, смогут быть обновлены до HarmonyOS. По мнению представителей компании, производительность устройств может увеличиться до 42%.


Подробности:


  1. Huawei представила первые мобильные устройства на HarmonyOS 2.0 []
  2. Huawei официально запускает Android-альтернативу HarmonyOS для смартфонов [(en)]
  3. HarmonyOS 2: что вам нужно знать о новой операционной системе Huawei [(en)]
  4. Huawei официально заменяет Android на HarmonyOS, которая также является Android [(en)]
  5. Компания Huawei объявила о замене Android на HarmonyOS на своих смартфонах []
  6. Huawei запускает HarmonyOS на телефонах, чтобы избавиться от Android[(en)]

Результаты исследования об условиях труда Open Source мейнтейнеров


Категория: Статьи/Дела организаций

Tfir пишет: Новый опрос, проведенный Tidelift, показал, что большинству разработчиков ПО с открытым исходным кодом не платят достаточно, если вообще платят за зачастую стрессовую и неблагодарную работу. Тем не менее, общественная польза от своей работы вот что мотивирует этих сопровождающих продолжать свою работу, несмотря на трудности. Почти половина мейнтейнеров добровольцы, не получающие зарплату. 46% не получают зарплату вообще, и только 26% зарабатывают более 1000 долларов в год за свои работы по техническому обслуживанию проектов. Tidelift оказывает поддержку: 52% мейнтейнеров Tidelift зарабатывают более 1000 долларов в год за свою работу по сравнению с только 17% тех, кто не сотрудничает с Tidelift. Три основных причины, по которым сопровождающим нравится их работа, это менять мир к лучшему (71%), удовлетворять потребность в творческой, сложной и / или приятной работе (63%) и работать над важными для меня проектами(59%).


Подробности:


  1. Тяжелая работа и низкая заработная плата вызывают стресс у мейнтейнеров проектов с открытым исходным кодом [(en)]
  2. Мейнтейнерам проектов с открытым исходным кодом мало платят интервью с Крисом Грамсом, главой маркетинга в Tidelift [(en)]
  3. Почти половина разработчиков открытого ПО добровольцы, не получающие зарплату [(en)]

Роснефть передала ноутбуки с ОС Astra Linux многодетным семьям


Категория: Новости/Внедрения

Сайт AstraLinux пишет: В Красноярском крае семьи, где трое и больше детей-школьников и нет финансовой возможности полноценно обеспечить их образование, получили 7260 ноутбуков ICL с ОС Astra Linux Common Edition. Первые 1930 устройств направили семьям из Красноярска, Дивногорска, Сосновоборска, Железногорска и ряда центральных районов края, а остальные 5330 жителям остальных муниципальных образований региона.


Подробности []


NocoDB, open-source аналог Airtable


Категория: Статьи/Базы данных

host_m пишет в блоге компании VDSina.ru на Хабре: Airtable классный инструмент, заслуживший признание у бизнеса по всему миру. Возможность работать с базами данных в удобном no-code интерфейсе с разными представлениями и типами данных не нова, но если в Spreadsheets (где таблица даже не является базой) данные приходилось конвертировать плагинами и костылями, то в Airtable рабочий процесс такой же плавный и удобный, как в Notion при работе с текстом. Но есть один нюанс: Airtable работает по модели сервиса с ограниченным бесплатным функционалом, а код, конечно, закрыт. К счастью, опенсорс-сообщество рано или поздно создаёт открытые альтернативы всем популярным сервисам, и благодаря совместной работе двух десятков разработчиков появился NocoDB.


Подробности []


Интервью с Дэниелом Скейлсом, главным юрисконсультом по бренду в Linux Foundation


Категория: Статьи/Дела организаций

Джейсон Перлоу, директор отдела аналитики проектов и редакционного контента Linux Foundation, поговорил с Дэниелом Скейлсом о важности защиты товарных знаков в проектах с открытым исходным кодом.


Вот некоторые из обсуждаемых вопросов:


  1. Обычно мы думаем о законах об интеллектуальной собственности и товарных знаках применительно к потребительским товарам и коммерческим организациям. В чем разница между ними и тем, когда проекты и организации с открытым исходным кодом используют бренды?
  2. Какие проблемы с товарными знаками возникали в сообществах разработчиков ПО с открытым исходным кодом?
  3. Почему Linux Foundation хорошее место для проектов с открытым исходным кодом, чтобы защитить свои бренды?
  4. Соответствие товарным знакам также может защитить проект от технических отклонений. Как можно использовать программу соответствия товарным знакам для поощрения соответствия кодовой базе или интерфейсам проекта?
  5. Отказываются ли проекты Linux Foundation от контроля над своей торговой маркой?

Подробности [(en)]


Google представил сервис для наглядного отслеживания зависимостей


Категория: Новости/Для разработчиков

OpenNET пишет: Компания Google ввела в строй новый сервис Open Source Insights (deps.dev), визуализирующий полный граф прямых и косвенных зависимостей для пакетов, распространяемых через репозитории NPM, Go, Maven и Cargo (в ближайшее время дополнительно появится поддержка NuGet и PyPI). Основным назначением сервиса является анализ распространения уязвимостей в модулях и библиотеках, присутствующих в цепочке зависимостей, что может оказаться полезным для выявления уязвимостей в зависимостях высокого уровня вложенности (зависимости зависимостей). Из возможных областей применения также называется изучение лицензионной чистоты проекта (показывается статистика о том, какие лицензии используются в зависимостях), отслеживание выхода новых версий и событий, связанных с зависимостями (например, выявление уязвимостей) и оценка зависимых проектов (можно посмотреть отчёт о том, какие проекты используют указанную библиотеку напрямую или через другие зависимости). В качестве источников данных используются репозитории пакетов и данные с GitHub, в том числе Issues.


Источник[]


История графической оболочки GNOME


Категория: Статьи/История

Популярный GNU/Linux видеоблогер Алексей Самойлов опубликовал новое видео: В прошлый раз мы рассмотрели историю развития и появления самого первого полноценного графического окружения Linux KDE. Однако не всем пришлось по нраву использование для его разработки проприетарного в те годы тулкита Qt. Фактически, сообщество раскололось на два лагеря: 1) тех, кому было в общем-то пофиг, ведь окружение свободно и его можно как угодно улучшать и модернизировать. 2) идейных приверженцев свободного ПО и 4-х свобод Столлмана в частности. Мексиканским программистом Мигелем де Икаса, также являющимся автором файлового менеджера Midnight Commander и библиотеки Mono, вместе со своим другом Федерико Кентеро был начат проект полностью свободного до самых костей графического окружения. Заранее хочу извиниться, если что-то упущу из рассказа. Я постарался выделить наиболее заметные и значительные этапы развития этого графического окружения.


Подробности []


Короткой строкой


Новости


Мероприятия


  1. Бесплатное онлайн-мероприятие Upstream для мейнтейнеров 7-го июня[(en)]
  2. Проект Zephyr отмечает 5-ю годовщину с новыми участниками и первым саммитом разработчиков Zephyr 8-10 июня [(en)]

Внедрения


  1. Facebook переводит все свои модели искусственного интеллекта на платформу PyTorch с открытым исходным кодом[ 1(en), 2(en)]
  2. Super Blueprints интегрируют стек с открытым исходным кодом 5G from Core to Door [(en)]
  3. ОС Astra Linux защищенная платформа в центре компетенций Ростелекома []

Открытие кода и данных


Компания Alibaba открыла код распределённой СУБД PolarDB, основанной на PostgreSQL []


Дела организаций


  1. Проект GCC разрешил приём изменений без передачи Фонду СПО прав на код [ 1(en), 2]
  2. Новые способы узнать об открытых организациях[(en)]
  3. Соперник TikTok, Kuaishou, присоединяется к Open Invention Network [(en)]
  4. GitLab приобретает UnReview, чтобы добавить на свою платформу больше инструментов машинного обучения [(en)]
  5. Фонд электронных рубежей осудил закрытие аккаунта PayPal одного из энтузиастов Tor []
  6. SUSE выбирает Calico от Tigera в качестве опции для RKE 2[(en)]
  7. MongoDB начинает 2022 финансовый год с сильной прибыли благодаря сильным продажам облачных продуктов [(en)]
  8. Фреймворк IBM LoopBack присоединяется к OpenJS Foundation в качестве инкубационного проекта [(en)]
  9. Еженедельник OSM 566 []
  10. Компания PINE64 стала спонсором KDE []

Ядро и дистрибутивы


  1. Обновление Linux предотвратит выход вашего устройства из строя[(en)]
  2. KDE Neon перешёл на Qt 5 Patch Collection []

Системное


В репозитории пакетного менеджера winget много дубликатов, плохо сформированных пакетов и искажённых манифестов []


Обучение


Linux Foundation и CNCF добавляют симулятор экзамена к сертификационным экзаменам Kubernetes[(en)]


Безопасность


  1. Серьёзный недостаток WordPress плагина Fancy Product Designer активно эксплуатируется[(en)]
  2. Уязвимость в Polkit, позволяющая повысить свои привилегии в системе []
  3. ХPaste от Southbridge для пересылки паролей и кода []
  4. Миллионы сайтов WordPress получили серьёзное обновление безопасности[(en)]
  5. Google Chrome теперь предупреждает вас, если вы собираетесь установить сомнительное расширение [(en)]

AI & Data Science


Open Source исследователи тестируют качество кода, сгенерированного искусственным интеллектом[(en)]


Web


  1. Google предлагает пользователям Chrome больший выбор по сравнению с новой спорной системой таргетированной рекламы[(en)]
  2. Google говорит, что Chrome помогает упростить переход к гибридной работе [(en)]

Пользовательское


На этой неделе в KDE: KCommandBar для сумасшедшей продуктивности []


Игры


Nvidia и Steam делают игры под Linux великими снова [(en)]


Статьи


DIY


О ходе создания игры Колобок в мае []


Ядро и дистрибутивы


Что представляет собой новая ОС Google Fuchsia[(en)]


Системное


Лучшие аналоги CPU-Z для Linux []


Специальное


  1. Введение вFreeDOS[(en)]
  2. Установите SSH-соединение между Windows и Linux [(en)]
  3. Как перемещаться по FreeDOS с CD и DIR [(en)]
  4. Свой лунапарк TFTP с блэкджеком и С++17 []
  5. Сеть в bitly: Linux tc для минимизации издержек и забавы ради []
  6. FreeDOS команды для фанов Linux [(en)]
  7. Об использовании переменных окружения в FreeDOS [(en)]

Базы данных


Grafana дашборды для pgSCV []


Безопасность


В коммерческом ПО широко распространён устаревший код с открытым исходным кодом: отчёт[(en)]


DevOps


  1. Уютный VPS-сервер для маленьких проектов за минимум денег: как настроить []
  2. Elastic расширяет поддержку osquery, инструментария с открытым исходным кодом для получения информации о хосте с помощью SQL-подобного языка запросов[(en)]
  3. Начните работу с Kubernetes, используя Chaos Engineering [(en)]
  4. Начните мониторинг своего кластера Kubernetes с помощью Prometheus и Grafana [(en)]
  5. Тестируйте отказы кластера Kubernetes и экспериментируйте прямо в своём терминале [(en)]
  6. Гибридная ИТ это больше, чем просто Kubernetes, работающий повсюду [(en)]
  7. Об экосистеме Kubernetes в 2021 году [(en)]
  8. О тестировании Kubernetes с помощью веб-интерфейса Chaos Mesh с открытым исходным кодом [(en)]
  9. Начало работы с Kustomize для управления конфигурацией Kubernetes [(en)]
  10. Рациональное использование ресурсов в Kubernetes []
  11. Ограниченияcf-push в Kubernetes-центричном мире разговор с Джулианом Фишером, CEO и основателем компании anynines [(en)]
  12. Антипаттерны деплоя в Kubernetes. Часть 2 []

AI & Data Science


  1. Лучшие библиотеки Python для науки о данных в 2021 году[(en)]
  2. Прогнозирование временных рядов с помощью AutoML []
  3. О внутреннем устройстве PyTouch, ML-библиотеки Facebook для обработки касаний[(en)]

Web


  1. Nyxt Browser это ориентированный на использование клавиатуры веб-браузер, вдохновленный Emacs и Vim[(en)]
  2. Как использовать REST и SOAP API в Zimbra OSE []
  3. i2pd-tools: дополнительные утилиты I2P []

Для разработчиков


  1. Мини-версия рантайма для программирования микроконтроллеров на D [ 1, 2]
  2. Буферы и окна: подробности о тайне ssh и цикла чтения while []
  3. О неоправданно хорошей работе [ -z $var ] []
  4. Создатель Python Гвидо Ван Россум обсуждает популярные языки программирования[(en)]
  5. Начало работы с бессерверными функциями и Java [(en)]
  6. Оптимизация бессерверных функций на Java в Kubernetes [(en)]
  7. 15 полезных сочетаний клавиш в Visual Studio Code для повышения производительности [(en)]

Пользовательское


Проверка орфографии в вашей программе из командной строки Linux[(en)]


Игры


Компьютерные игры в Linux: насколько это сложно?[(en)]


Железо


Домашний сервер []


Разное


  1. Как установить Chia на Ubuntu []
  2. Безуспешная попытка монетизации моего проекта в open source []
  3. Преобразование изображений в формат ASCII в терминале Linux с помощью Ascii Image Converter [(en)]

Релизы


Ядро и дистрибутивы


  1. Релиз дистрибутива openSUSE Leap 15.3 [ 1, 2, 3(en)]
  2. Релиз дистрибутива для исследования безопасности Kali Linux 2021.2 [ 1(en), 2]
  3. AlmaLinux OS 8.4: свободная альтернатива CentOS [(en)]
  4. Доступен JingOS 0.9, дистрибутив для планшетных ПК []
  5. Tails 4.19 []
  6. ОС Альт Образование 9.2 готовое рабочее место педагога, студента, школьника []
  7. Выпуск дистрибутива NixOS 21.05, использующего пакетный менеджер Nix []
  8. Выпуск дистрибутива Clonezilla Live 2.7.2 []
  9. Выпуск Chrome OS 91 []
  10. Выпуск CentOS Linux 8.4 (2105) []

Системное


Выпуск Util-linux 2.37 []


Специальное


  1. Выпуск OpenRGB 0.6, инструментария для управления устройствами c RGB-подсветкой []
  2. Выпуск Wine 6.10 []

Базы данных


Выпуск СУБД Firebird 4.0 с поддержкой репликации []


Мультимедиа


Выпуск системы потокового видеовещания OBS Studio 27.0 []


Web


  1. Релиз Firefox 89 с переработанным интерфейсом [ 1, 2, 3, 4(en)]
  2. Выпуск сервера приложений NGINX Unit 1.24.0 []
  3. Выпуск децентрализованной видеовещательной платформы PeerTube 3.2 []
  4. Релиз http-сервера Apache 2.4.48 []
  5. Выпуск Tor Browser 10.0.17 и дистрибутива Tails 4.19 []
  6. Доступен децентрализованный коммуникационный клиент Jami Maloya []
  7. Выпуск NeoChat 1.2 []

Для разработчиков


  1. Выпуск библиотеки с реализацией регулярных выражений PCRE2 10.37 [ 1, 2]
  2. Выпуск Electron 13.0.0, платформы создания приложений на базе движка Chromium [ 1, 2]
  3. Microsoft представила собственный бесплатный дистрибутив OpenJDK, пообещав длительную поддержку [ 1, 2]
  4. Выпуск интегрированной среды разработки Apache NetBeans 12.4 []
  5. Выпуск языка программирования Til 0.2 []
  6. Выпуск r-test v0.1.0 инструмента для исследования эффективности кэширования файлов при нехватке памяти []
  7. Выпуск сборочного инструментария Qbs 1.19 []
  8. Выпуск cache-bench 0.1.0 для исследования эффективности кэширования файлов при нехватке памяти []

Пользовательское


  1. Релиз утилиты для создания скриншотов Ksnip 1.9.0 []
  2. Выпуск десктоп-окружения Cinnamon 5.0 []

Игры


Выпуск игры Free Heroes of Might and Magic II (fheroes2) 0.9.4 [ 1, 2]


Что ещё посмотреть


  1. Новые функции в Python 3.0, шпаргалка по grep, бесплатные онлайн-курсы и вторая часть Red Hat Summit Virtual Experience []
  2. Open-Source проект недели по версии SD Times: Project Reaqtor [(en)]

Заключение


На этом всё, до следующего воскресенья!


Подписывайтесь на наш Telegram канал наш Telegram канал или RSS чтобы не пропустить новые выпуски FOSS News. Также мы есть во всех основных соцсетях:


  1. Fediverse[]
  2. ВКонтакте[]
  3. Facebook[]
  4. Twitter[]

[] Предыдущий выпуск





Если кто интересуется составлением дайджестов и имеет время и возможность помочь буду рад, пишите по контактам, указанным в моём профиле, или в личные сообщения. В первую очередь нужны люди, готовые помогать в разборе материалов, собранных роботом по нескольким десяткам англо- и русскоязычных источников, а именно разработчики, которые хотели бы поучаствовать в доработке средств автоматизации под многопользовательский режим (скорее всего это будет в форме Telegram чат-бота на Python), и просто активисты, которые смогли бы тратить несколько часов в неделю на работу с будущим автоматизированным категоризатором (записываться уже можно, уведомим по готовности инструмента). Подробнее о внутренней кухне дайджестов можно прочитать в спецвыпуске FOSS News [].






Думаю, все в курсе сложной ситуации, в которой оказался FSF (Фонд Свободного ПО) из-за конфликта вокруг его основателя Ричарда Столлмана. Подробности можно посмотреть в наших подборках новостей [ 1, 2]. Я считаю, что самое время поддержать Фонд вступлением и финансами []. FSF это одна из немногих организаций, бескомпромиссно стоящих на защите интересов большинства людей, использующих компьютеры в работе, общественной активности и для личных дел. А чтобы организация полностью работала в интересах людей, она должна этими людьми и финансироваться. К слову, 80% финансирования FSF идёт от частных лиц.

Подробнее..

FOSS News 74 дайджест материалов о свободном и открытом ПО за 713 июня 2021 года

13.06.2021 22:06:30 | Автор: admin

Всем привет!


Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире.


Главные темы нового выпуска:


  1. Facebook открыл доступ к самой большой языковой базе для разработчиков переводчиков.
  2. Самое ценное под защитой ОС Альт: Республика Калмыкия перевела на ОС Альт медучреждения, на очереди школы.
  3. Онлайн-хакатон SSL: Safety & Security Lab.
  4. Open source это сообщество, а не бренд. О построении бизнес-модели на открытых исходниках.
  5. Битва открытых лицензий.
  6. Как Replit пыталась отжать open-source проект.
  7. Невероятное демо и немного о Sun Microsystems.
  8. История Linux Live CD.

И многое другое



Оглавление


  1. Главное
    1. Facebook открыл доступ к самой большой языковой базе для разработчиков переводчиков
    2. Самое ценное под защитой ОС Альт: Республика Калмыкия перевела на ОС Альт медучреждения, на очереди школы
    3. Онлайн-хакатон SSL: Safety & Security Lab
    4. Open source это сообщество, а не бренд. О построении бизнес-модели на открытых исходниках
    5. Битва открытых лицензий
    6. Как Replit пыталась отжать open-source проект
    7. Невероятное демо и немного о Sun Microsystems
    8. История Linux Live CD
  2. Короткой строкой
    1. Новости
      1. Мероприятия
      2. Внедрения
      3. Открытие кода и данных
      4. Дела организаций
      5. Ядро и дистрибутивы
      6. Системное
      7. Специальное
      8. Обучение
      9. Мультимедиа
      10. Мобильные
      11. Безопасность
      12. DevOps
      13. AI & Data Science
      14. Web
      15. Пользовательское
      16. Игры
      17. Железо
    2. Статьи
      1. Мероприятия
      2. Дела организаций
      3. DIY
      4. Ядро и дистрибутивы
      5. Системное
      6. Специальное
      7. Обучение
      8. Базы данных
      9. Мультимедиа
      10. Мобильные
      11. Безопасность
      12. DevOps
      13. AI & Data Science
      14. Web
      15. Для разработчиков
      16. Менеджмент
      17. Пользовательское
      18. Разное
    3. Релизы
      1. Ядро и дистрибутивы
      2. Системное
      3. Специальное
      4. Базы данных
      5. Мультимедиа
      6. DevOps
      7. Web
      8. Для разработчиков
      9. Пользовательское
  3. Что ещё посмотреть
  4. Заключение

Главное


Facebook открыл доступ к самой большой языковой базе для разработчиков переводчиков


Категория: Новости/Открытие кода и данных

Analyticsindiamag пишет: Отдел искусственного интеллекта Facebook недавно объявил, что откроет исходный код для своей базы данных FLORES-101, чтобы исследователи могли использовать её для улучшения моделей многоязычного перевода. FLORES-101 это набор оценочных данных многоязычного перевода для 101 языка. База данных вместе с техническим отчётом и моделями доступна здесь для бесплатного использования исследователями и разработчиками по всему миру. Facebook утверждает, что публичный доступ к такой информации позволит исследователям ускорить развитие многоязычных систем перевода во всём мире.


Подробности:


  1. [(en)]
  2. []

Самое ценное под защитой ОС Альт: Республика Калмыкия перевела на ОС Альт медучреждения, на очереди школы


Категория: Новости/Внедрения

Базальт СПО пишет 7-го июня: Сегодня все врачи Республики Калмыкия работают на компьютерах под управлением российской защищенной операционной системы Альт 8 СП. В 2019-2020 в рамках регионального проекта цифровизации здравоохранения гг. было развернуто более 2 тысяч автоматизированных рабочих мест (АРМ). Этот опыт был признан настолько успешным, что Министерство цифрового развития Республики Калмыкия заключило с Базальт СПО соглашение о долгосрочном комплексном сотрудничестве. Оно уже развивается сразу по нескольким направлениям: внедрение ОС Альт в школах республики, совместные конференции и семинары, обучение ИТ-специалистов и пользователей. Например, первая группа системных администраторов организаций здравоохранения Калмыкии успешно прошла дистанционное обучение по программе администрирования ОС ALTSTART. Интенсив. В ближайших совместных планах Минцифры Калмыкии и Базальт СПО пилотное внедрение ОС Альт в школах Калмыкии и открытие центра компетенций Базальт СПО. Программное обеспечение предоставляется школам на льготных условиях.


Подробности []


Онлайн-хакатон SSL: Safety & Security Lab


Категория: Новости/Мероприятия

Теплица социальных технологий анонсировала онлайн-хакатон SSL: Safety & Security Lab. Организаторы пишут: Команда Теплицы социальных технологий приглашает присоединиться к созданию технологических решений, игр и просветительских проектов на онлайн-хакатоне SSL: Safety & Security Lab. Мы ждём разработчиков, UX-дизайнеров, аналитиков, общественных активистов, независимых журналистов, блогеров, популяризаторов цифровых прав и всех, кому дороги ценности персональной независимости, приватности и гражданских свобод. На этот раз участники хакатона SSL: Safety & Security Lab создадут медиапроекты, сервисы, приложения, онлайн-игры, другие проекты и инструменты, которые помогут повысить уровень комплексной защищенности гражданского общества, опираясь на российскую повестку. Мероприятие пройдет онлайн.


По словам менеджера событий Теплицы Алисы Цветковой Абсолютно все проекты, которые будут созданы на хакатоне будут выставлены с открытым кодом.


Подробности []


Open source это сообщество, а не бренд. О построении бизнес-модели на открытых исходниках


Категория: Статьи/Дела организаций

SD Times пишет: Зачем использовать открытый исходный код уже не вопрос. Ситуация изменилась, и компании задаются вопросом, почему они не используют открытый исходный код? Но остался без ответа ещё более серьёзный вопрос: как они используют открытый исходный код? Остаются ли они верными концепции открытого исходного кода?. В статье поднимаются вопросы точного определения открытого кода, бизнес модели на его основе, отдача сообществу, вызовы перед сообществом Open Source и использование открытого кода в корпорациях.


Подробности [(en)]


Битва открытых лицензий


Категория: Статьи/Юридические вопросы

SD Times развивает предыдущую тему: Ранее в этом году Elastic возобновил дебаты о лицензировании открытого исходного кода, объявив, что изменит свою лицензионную модель, чтобы лучше защитить свой открытый исходный код. За последние пару лет ряд компаний, в том числе Redis Labs, MongoDB, Cockroach Labs и Confluent, изменили свои лицензии на открытый исходный код, чтобы избежать того, что они называют большой кражей кода, когда облачные провайдеры, такие как Amazon, берут их успешный проект с открытым исходным кодом, используют его как облачный сервис и получают прибыль, не отдавая при этом ничего сообществу. Издание приводит мнения нескольких участников сообщества по теме этого конфликта.


Подробности [(en)]


Как Replit пыталась отжать open-source проект


Категория: Статьи/Юридические вопросы

MagisterLudi опубликовал в блоге компании Маклауд перевод статьи о показательном примере противостояния сообщества открытого кода в лице одного интереса и бизнеса в вопросах интеллектуальной собственности. Это история о том, как Replit использует юридические угрозы и свое венчурное финансирование, чтобы заставить меня закрыть проект с открытым исходным кодом, который им не нравится краткое содержание статьи. Конфликт вызвал большое внимание и, в свете не такой уж давней истории о конфликте NGINX и Rambler, говорит о том, что конфликт интересов (реальный или раздутый) может возникнуть в то время и в том случае когда его не ждёшь и что сообщество и отдельные разработчики должны уметь защищаться.


Подробности []


Невероятное демо и немного о Sun Microsystems


Категория: Статьи/Разное

Эпичная история как автору Open Source проекта презентовали его же код. Просто почитайте :)


Подробности []


История Linux Live CD


Категория: Статьи/История

Stormglass опубликовал в блоге компании QIWI перевод статьи об истории одного из знаковых предметов в истории GNU/Linux: Продать новую идею может быть тяжело, особенно в случае, если аудитория может её не принять. Возможно, ей интересно было бы попробовать новый продукт, но только если усилия окажутся минимальными. Люди хотят, чтобы при первом признаке опасности у них под рукой была кнопка Выход. Последние 20 лет это было практически девизом Linux Live CD: вставьте этот диск (или USB-флэшку) в свой компьютер, попробуйте систему, посмотрите, понравится ли она вам. Если она вам понравится, установите её. Возможно, вам трудно представить, как мы пришли к такому вполне привычному сейчас формату, когда частью Linux является физический компонент. Это было огромным конкурентным преимуществом Linux. В сегодняшней статье мы расскажем о необычной истории самых первых live CD Linux.


Подробности []


Короткой строкой


Новости


Мероприятия


  1. Вторые открытые соревнования для детей и подростков по GNU/Linux[ 1, 2]
  2. Программа объединенной конференции СПО: от обучения до разработки []
  3. Онлайн-митап для Android-разработчиков []

Внедрения


В МФЦ Орловской области можно получать государственные и муниципальные услуги с помощью полностью отечественных решений []


Открытие кода и данных


  1. Исходный код RTS Периметр выложен в OpenSource []
  2. Компания LG опубликовала систему проверки соблюдения открытых лицензий []

Дела организаций


  1. Mozilla, Google, Apple и Microsoft объединили усилия в стандартизации платформы для браузерных дополнений [ 1, 2(en)]
  2. Экосистема WordPress принесла более половины триллиона долларов доходов [(en)]
  3. Mozilla создала площадку для обсуждения идей и предложений []
  4. The Zephyr Project Celebrates 5th Anniversary with new members and inaugural Zephyr Developer Summit on June 8-10 [(en)]
  5. Hyperledger объявляет об исследовании брендов блокчейнов 2021 года [(en)]
  6. API-шлюз с открытым исходным кодом KrakenD становится проектом Linux Foundation [(en)]
  7. Платформа продуктовой аналитики с открытым исходным кодом PostHog привлекла 15 миллионов долларов [(en)]
  8. FINOS объявляет об исследовании состояния проектов с открытым исходным кодом в сфере финансовых услуг на 2021 год [(en)]
  9. TODO Group объявляет об исследовании состояния OSPO в 2021 году [(en)]
  10. Fairwinds объявляет о создании группы пользователей ПО с открытым исходным кодом [(en)]
  11. Еженедельник OSM 567 []

Ядро и дистрибутивы


Линус Торвальдс: нагруженный релиз-кандидат Linux 5.13 не вызывает серьёзных опасений[(en)]


Системное


В Wayland-драйвере для Wine появилась поддержка Vulkan и многомониторных конфигураций []


Специальное


IonQ интегрируется с Cirq фреймворком квантовых вычислений с открытым исходным кодом от Google[(en)]


Обучение


TransTech Social и Linux Foundation объявляют о стипендии для обучения и сертификации [ 1(en), 2]


Мультимедиа


Kodi 20 получит название Nexus []


Мобильные


  1. Второй бета-выпуск мобильной платформы Android 12 [ 1, 2(en), 3(en), 4(en)]
  2. Plasma Mobile: Больше приложений и улучшенный домашний экран []

Безопасность


  1. GitHub раскрывает свой план по выявлению вредоносных программ и эксплойтов, размещенных на платформе[(en)]
  2. В Fedora 35 намечен переход на yescrypt для хэширования паролей []
  3. Arch Linux прекращает поддержку MD5 и SHA1 для новых паролей []
  4. Linux-дистрибутивы для анонимной работы в интернете что нового? []
  5. Microsoft заявляет, что Kubernetes является целью атак криптомайнинга [(en)]
  6. Google Chrome вынужден исправить очередную zero-day уязвимость [(en)]
  7. Эксперт обнаружил критическую уязвимость в библиотеке Polkit (PolicyKit) для Linux, баг в коде был с 2014 года []

DevOps


Grafana Labs представляет новые функции мониторинга[ 1(en), 2(en)]


AI & Data Science


Новый проект с открытым исходным кодом ISAC-SIMO использует машинное обучение для контроля качества строительства в развивающихся странах[(en)]


Web


Google признал неудачным эксперимент с показом только домена в адресной строке Chrome [ 1, 2(en), 3(en), 4(en)]


Пользовательское


На этой неделе в KDE: множество улучшений производительности []


Игры


Nvidia и Valve привносят DLSS в игры для Linux в некотором роде[(en)]


Железо


В новом ThinkPad от Lenovo есть одно крупное обновление для Linux[(en)]


Статьи


Мероприятия


Чего ожидать на саммите Cloud Foundry Summit 2021[ 1(en), 2(en)]


Дела организаций


Зачем GitLab купил UnReview?[(en)]


DIY


  1. Научный калькулятор с открытым исходным кодом[(en)]
  2. OpenSource-метод позволят делать двусторонние платы с переходными отверстиями в домашних условиях [(en)]

Ядро и дистрибутивы


  1. Как загружаетсяFreeDOS [(en)]
  2. Видео: antiX 19.4 и AV Linux []

Системное


Запускаем Homebrew на Windows 10 []


Специальное


  1. Несколько материалов о работе в FreeDOS[ 1(en), 2(en), 3(en), 4(en)]
  2. Установка Asterisk в Debian 10 []
  3. Анализ показателей здоровья сообщества с помощью Cauldron и GrimoireLab[(en)]
  4. Почему стоит выбрать открытый исходный код для проекта домашней автоматизации [(en)]
  5. RudderStack представляет платформы обработки клиентских данных с открытым исходным кодом для разработчиков [(en)]
  6. VGA библиотека для Raspberry Pi Pico [(en)]

Обучение


  1. 5 удобных руководств по открытому исходному коду для учителей[(en)]
  2. История человека, преподающего Python на Raspberry Pi 400 в публичной библиотеке [(en)]

Базы данных


  1. Настройте свои запросы MySQL как профессионал[(en)]
  2. Linux Fu: базы данных файловые системы нового уровня [(en)]
  3. Измеряем расходы на память у Postgres процессов []
  4. Введение в MySQL: установка, настройка и поддержка в Ubuntu[(en)]

Мультимедиа


Subtitld: кроссплатформенный редактор субтитров[(en)]


Мобильные


Красивый изменяющий цвет пользовательский интерфейс Android 12 уже оправдывает хайп[(en)]


Безопасность


  1. Проверка настроек безопасности в Linux с помощью checksec[(en)]
  2. Безопасность встраиваемых систем Linux []
  3. Dockle Диагностика безопасности контейнеров []
  4. Как использовать Python для проверки протокола Signal []

DevOps


  1. Kubevious революционная панель управления Kubernetes []
  2. Как увеличить скорость реакции Kubernetes на отказ узлов кластера? []
  3. Тестирование сбоев произвольных подов на Kubernetes с помощью kube-monkey[(en)]
  4. Бенчмаркинг Linkerd и Istio []
  5. Что происходит, когда вы намеренно закрываете контейнеры Kubernetes?[(en)]
  6. Проблемы миграции служб данных из Cloud Foundry в Kubernetes [(en)]
  7. Acme.sh + Ansible + Alias mode: Автоматизируем получение и распространение TLS сертификатов []
  8. Автоматизация настройки рабочего окружения или как доставить Linux тем, у кого его нет []
  9. Антипаттерны деплоя в Kubernetes. Часть 3 []
  10. Как правильно сделать Kubernetes (обзор и видео доклада) []
  11. Tоп 10 PromQL запросов для мониторинга Kubernetes []

AI & Data Science


  1. Как добавить Natural Language Processing в Minecraft []
  2. Руководство по GPT Neo для начинающих (с кодом на Python)[(en)]
  3. Проект Plot от Observable помогает с визуализацией данных [(en)]
  4. Руководство по Precision-Recall Tradeoff на Python [(en)]
  5. Сценарии для виртуальных ассистентов Салют на NodeJS и фреймворке SaluteJS []
  6. Как PyTorch в последнее время бросает вызов TensorFlow[(en)]
  7. 8 альтернатив TensorFlow Serving [(en)]

Web


  1. Может ли новый внешний вид Firefox спасти этот веб-браузер?[(en)]
  2. Приложение, работающее через I2P: проще, чем кажется []
  3. Appwrite, open-source бэкэнд-платформа []

Для разработчиков


  1. Утилиты для обработки JSON []
  2. От Планеты GitHub с любовью []
  3. Создание переносимых функций на бессерверных платформах с помощью Quarkus Funqy[(en)]
  4. Каждый Java Junior делает это: распространенные ошибки Java, совершаемые новичками [(en)]
  5. Как гипертекст позволяет работать с состоянием приложения в REST [(en)]

Менеджмент


Чтобы воспитывать открытых лидеров, менеджеры должны научиться отпускать[(en)]


Пользовательское


  1. Сравнение Linux Mint и Fedora: что лучше?[(en)]
  2. Helix: текстовый редактор в терминале для опытных пользователей Linux [(en)]
  3. RTFM! Как читать (и понимать) фантастические страницы руководства в Linux [(en)]
  4. Установка Dash to Dock в Ubuntu 20.04 []
  5. angelspie управление окнами в X11, глобальные и не только горячии клавиши []
  6. Видеообзор Plasma 5.22 на русском от PLAFON []

Разное


  1. Играйте в Doom на Kubernetes[(en)]
  2. Об открытом исходном коде и открытых стандартах [(en)]
  3. Линус Торвальдс вступил в дискуссию с антипрививочником в списке рассылки ядра Linux []

Релизы


Ядро и дистрибутивы


  1. Выпуск Lakka 3.1, дистрибутива для создания игровых консолей []
  2. Выпуск дистрибутива для резервного копирования Rescuezilla 2.2 []
  3. Кандидат в релизы дистрибутива Rocky Linux 8.4, идущего на смену CentOS []
  4. Выпуск дистрибутива Redcore Linux 2101 []

Системное


  1. Выпуск дисплейного сервера Mir 2.4 []
  2. Релиз загрузочного менеджера GNU GRUB 2.06 []

Специальное


  1. Выпуск редактора двоичных данных GNU Poke 1.3 []
  2. Выпуск Proton 6.10-GE-1, расширенной сборки Proton, пакета для запуска Windows-игр в Linux []

Базы данных


Apache Cassandra 4.0: устранение задержек с помощью Java 16 ZGC[(en)]


Мультимедиа


  1. Выпуск свободной системы 3D-моделирования Blender 2.93 LTS [ 1, 2, 3]
  2. Выпуск мультимедийного проигрывателя QMPlay2 21.06.07 []
  3. Обновление медиапроигрывателя VLC 3.0.15 []
  4. video2midi 0.4.5.2 []

DevOps


  1. Что нового вLinkerd 2.10 взгляд Джейсона Моргана, технического евангелиста Linkerd в Buoyant [(en)]
  2. Знакомьтесь: Argo Rollouts v1.0 []

Web


  1. Выпуск vsftpd 3.0.4 []
  2. Обновление Chrome 91.0.4472.101 с устранением 0-day уязвимости []

Для разработчиков


  1. Zig 0.8 []
  2. Выпуск системы управления исходными текстами Git 2.32 []
  3. Вышел релиз GitLab 13.12 с запуском DAST по требованию и графиком частоты развёртывания []

Пользовательское


  1. Релиз рабочего стола KDE Plasma 5.22 [ 1, 2, 3, 4]
  2. Выпуск рабочего стола Regolith 1.6 []
  3. Релиз оконного менеджера IceWM 2.4 []
  4. Представляем Windows Terminal Preview 1.9 []
  5. kchmviewer вышла версия 8.0 []
  6. Обновление KDE Gear 21.04.2, набора приложений от проекта KDE []

Что ещё посмотреть


  1. Дайджест opensource.com: новый сельскохозяйственный проект с открытым исходным кодом, опрос Stack Overflow и чествование разработчиков открытого исходного кода[(en)]
  2. Open-Source проект недели по версии SD Times: page-fetch [(en)]

Заключение


На этом всё, до следующего воскресенья!


Подписывайтесь на наш Telegram канал наш Telegram канал или RSS чтобы не пропустить новые выпуски FOSS News. Также мы есть во всех основных соцсетях:


  1. Fediverse[]
  2. ВКонтакте[]
  3. Facebook[]
  4. Twitter[]

[] Предыдущий выпуск





Если кто интересуется составлением дайджестов и имеет время и возможность помочь буду рад, пишите по контактам, указанным в моём профиле, или в личные сообщения. В первую очередь нужны люди, готовые помогать в разборе материалов, собранных роботом по нескольким десяткам англо- и русскоязычных источников, а именно разработчики, которые хотели бы поучаствовать в доработке средств автоматизации под многопользовательский режим (скорее всего это будет в форме Telegram чат-бота на Python), и просто активисты, которые смогли бы тратить несколько часов в неделю на работу с будущим автоматизированным категоризатором (записываться уже можно, уведомим по готовности инструмента). Подробнее о внутренней кухне дайджестов можно прочитать в спецвыпуске FOSS News [].






Думаю, все в курсе сложной ситуации, в которой оказался FSF (Фонд Свободного ПО) из-за конфликта вокруг его основателя Ричарда Столлмана. Подробности можно посмотреть в наших подборках новостей [ 1, 2]. Я считаю, что самое время поддержать Фонд вступлением и финансами []. FSF это одна из немногих организаций, бескомпромиссно стоящих на защите интересов большинства людей, использующих компьютеры в работе, общественной активности и для личных дел. А чтобы организация полностью работала в интересах людей, она должна этими людьми и финансироваться. К слову, 80% финансирования FSF идёт от частных лиц.

Подробнее..

Перевод Внутренности Linux как procselfmem пишет в недоступную для записи память

26.05.2021 12:10:08 | Автор: admin

Странная причудливость псевдофайла /proc/*/mem заключается в его пробивной семантике. Операции записи через этот файл будут успешными даже если целевая виртуальная память помечена как недоступная для записи. Это сделано намеренно, и такое поведение активно используется проектами вроде компилятора Julia JIT или отладчика rr.

Но возникают вопросы: подчиняется ли привилегированный код разрешениям виртуальной памяти? До какой степени оборудование может влиять на доступ к памяти ядра?

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

Патчим libc с помощью /proc/self/mem


Как выглядит эта пробивная семантика? Рассмотрим код:

#include <fstream>#include <iostream>#include <sys/mman.h>/* Write @len bytes at @ptr to @addr in this address space using * /proc/self/mem. */void memwrite(void *addr, char *ptr, size_t len) {  std::ofstream ff("/proc/self/mem");  ff.seekp(reinterpret_cast<size_t>(addr));  ff.write(ptr, len);  ff.flush();}int main(int argc, char **argv) {  // Map an unwritable page. (read-only)  auto mymap =      (int *)mmap(NULL, 0x9000,                  PROT_READ, // <<<<<<<<<<<<<<<<<<<<< READ ONLY <<<<<<<<                  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);  if (mymap == MAP_FAILED) {    std::cout << "FAILED\n";    return 1;  }  std::cout << "Allocated PROT_READ only memory: " << mymap << "\n";  getchar();  // Try to write to the unwritable page.  memwrite(mymap, "\x40\x41\x41\x41", 4);  std::cout << "did mymap[0] = 0x41414140 via proc self mem..";  getchar();  std::cout << "mymap[0] = 0x" << std::hex << mymap[0] << "\n";  getchar();  // Try to writ to the text segment (executable code) of libc.  auto getchar_ptr = (char *)getchar;  memwrite(getchar_ptr, "\xcc", 1);  // Run the libc function whose code we modified. If the write worked,  // we will get a SIGTRAP when the 0xcc executes.  getchar();}

Здесь /proc/self/mem используется для записи в две недоступные для записи страницы памяти. Первая содержит сам код, а вторая принадлежит libc (функции getchar). Последняя часть вызывает больший интерес: код записывает байт 0xcc (точка прерывания в приложениях под x86-64), который в случае своего исполнения заставит ядро предоставить нашему процессу SIGTRAP. Это буквально меняет исполняемый код libc. И если при следующем вызове getchar мы получим SIGTRAP, то будем знать, что запись была успешной.

Вот как это выглядит при запуске программы:


Работает! Посередине выводятся выражения, которые доказывают, что значение 0x41414140 было успешно записано и считано из памяти. Последний вывод показывает, что после патчинга наш процесс получил SIGTRAP в результате нашего вызова getchar.

На видео:


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

Оборудование


На платформе x86-64 есть две настройки процессора, которые управляют возможностью ядра обращаться к памяти. Они применяются модулем управления памятью (MMU).

Первая настройка бит защиты от записи, Write Protect bit (CR0.WP). Из руководства Intel (том 3, раздел 2.5) мы знаем:

Защита от записи (16-й бит CR0). Если задана, он не даёт процедурам уровня супервизора записывать в защищённые от записи страницы. Если бит пуст, то процедуры уровня супервизора могут записывать в защищённые от записи страницы (вне зависимости от настроек бита U/S; см. раздел 4.1.3 и 4.6).

Это не позволяет ядру записывать в защищённые от записи страницы, что, естественно, по умолчанию разрешено.

Вторая настройка предотвращение доступа в режиме супервизора, Supervisor Mode Access Prevention (SMAP) (CR4.SMAP). Полное описание, приведённое в томе 3, в разделе 4.6, многословное. Если вкратце, то SMAP полностью лишает ядро способности записывать или читать из памяти пользовательского пространства. Это предотвращает эксплойты, которые наполняют пользовательское пространство зловредными данными, которые ядро должно прочитать в ходе исполнения.

Если код ядра использует для доступа к пользовательскому пространству только одобренные каналы (copy_to_user и т.д.), то SMAP можно смело игнорировать, эти функции автоматически задействуют его до и после обращения к памяти. А что насчёт защиты от записи?

Если CR0.WP не задан, то реализация /proc/*/mem в ядре действительно сможет бесцеремонно записывать в защищённую от записи память пользовательского пространства.

Однако CR0.WP задаётся при загрузке и обычно живёт в течение всего времени работы систем. В этом случае при попытке записи будет выдаваться сбой страницы. Это, скорее, инструмент для копирования при записи (Copy-on-Write), чем средство защиты, поэтому не накладывает на ядро никаких реальных ограничений. Иными словами, требуется неудобная обработка сбоев, которая не обязательна при заданном бите.

Давайте теперь разберёмся с реализацией.

Как работает /proc/*/mem


/proc/*/mem реализован в fs/proc/base.c.

Структура file_operations содержит функции обработчика, а функция mem_rw() полностью поддерживает обработчик записи. mem_rw() использует для операций записи access_remote_vm(). А access_remote_vm() делает вот что:

  • Вызывает get_user_pages_remote(), чтобы найти физический фрейм, соответствующий целевому виртуальному адресу.
  • Вызывает kmap(), чтобы пометить этот фрейм доступный для записи в виртуальном адресном пространстве ядра.
  • Вызывает copy_to_user_page() для финального выполнения операций записи.

Эта реализация полностью обходит вопрос о способности ядра записывать в незаписываемую память пользовательского пространства! Контроль ядра над подсистемой виртуальной памяти позволяет полностью обойти MMU, позволяя ядру просто записывать в свое собственное адресное пространство, доступное для записи. Так что обсуждения CR0.WP становится неактуальным.

Рассмотрим каждый из этапов:

get_user_pages_remote()

Для обхода MMU ядру нужно, чтобы в приложении было вручную выполнено то, что MMU делает аппаратно. Сначала необходимо преобразовать целевой виртуальный адрес в физический. Этим занимается семейство функций get_user_pages(). Они проходят по таблицам страниц и ищут фреймы физической памяти, которые соответствуют заданному диапазону виртуальных адресов.

Вызывающий предоставляет контекст и с помощью флагов меняет поведение get_user_pages(). Особенно интересен флаг FOLL_FORCE, который передаётся mem_rw(). Флаг запускает check_vma_flags (логику проверки доступа в get_user_pages()), чтобы игнорировать запись в незаписываемые страницы и продолжить поиск. Пробивная семантика полностью относится к FOLL_FORCE (комментарии мои):

static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags){        [...]        if (write) { // If performing a write..                if (!(vm_flags & VM_WRITE)) { // And the page is unwritable..                        if (!(gup_flags & FOLL_FORCE)) // *Unless* FOLL_FORCE..                                return -EFAULT; // Return an error        [...]        return 0; // Otherwise, proceed with lookup}

get_user_pages() стоже соблюдает семантику копирования при записи (CoW). Если определяется запись в таблицу незаписываемой страницы, то эмулируется сбой страницы с помощью вызова handle_mm_fault, основного обработчика страничных ошибок. Это запускает соответствующую подпрограмму обработки копирования при записи посредством do_wp_page, которая при необходимости копирует страницу. Так что если записи через /proc/*/mem выполняются приватным разделяемым маппингом, например, libc, то они видимы только в рамках процесса.

kmap()

После того, как найден физический фрейм, его нужно отобразить в виртуальное адресное пространство ядра, доступным для записи. Делается это с помощью kmap().

На 64-битной платформе x86 вся физическая память отображается через область линейного отображения виртуального адресного пространства ядра. В этом случае kmap() работает очень просто: ему лишь нужно добавить начальный адрес линейного отображения в физический адрес фрейма, чтобы вычислить виртуальный адрес, в который отображён этот фрейм.

На 32-битной платформе x86 линейное отображение содержит подмножество физической памяти, так что функции kmap() может потребоваться отобразить фрейм с помощью выделения highmem-памяти и манипулирования таблицами страницы.

В обоих случая линейное отображение и highmem-отображение выполняются с защитой PAGE_KERNEL, которая позволяет запись.

copy_to_user_page()

Последний этап выполнение записи. Это делается с помощью copy_to_user_page(), по сути memcpy. Это работает, поскольку целью является записываемое отображение из kmap().

Обсуждение


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

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

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

Заключение


Изучив подробности пробивной семантики в реализации /proc/*/mem мы можем отразить взаимосвязи между ядром и процессором. На первый взгляд, способность ядра писать в недоступную для записи память вызывает вопрос: до какой степени процессор может влиять на доступ ядра к памяти? В руководстве описаны механизмы управления, которые могут ограничивать действия ядра. Но при внимательном рассмотрении оказывается, что ограничения в лучшем случае поверхностны. Это простые препятствия, которые можно обойти.
Подробнее..

Свой ремейк ZX игры Reskue в Steam

12.06.2021 16:15:59 | Автор: admin

Да, понимаю, что это игра про учёных, но это не игра про немого учёного с монтировкой с цифрой 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. У меня там несколько проектов.

Подробнее..

Acme.sh Ansible Alias mode Автоматизируем получение и распространение TLS сертификатов

09.06.2021 20:16:20 | Автор: admin

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

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

Анимация manual modeАнимация manual mode

После этого добавления нужно подождать какое-то время, что бы запись зарезолвилась и выполнить такую же команду, только с --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 провайдера.

Анимация API modeАнимация API mode

Под 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.

Анимация alias modeАнимация alias mode

Разберём последовательно. Для демонстрации я купил домен 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, валидность сертификатов.

Подробнее..

Перевод Находим и устраняем уязвимости бинарных файлов в Linux с утилитой checksec и компилятором gcc

12.06.2021 16:15:59 | Автор: admin

Изображение: Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

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

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

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

  • как использовать утилиту checksec для поиска уязвимостей;
  • как использовать компилятор gcc для устранения найденных уязвимостей.

Установка checksec


Для Fedora OS и других систем на базе RPM:

$ sudo dnf install checksec

Для систем на базе Debian используйте apt.

Быстрый старт с checksec


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

$ file /usr/bin/checksec/usr/bin/checksec: Bourne-Again shell script, ASCII text executable, with very long lines$ wc -l /usr/bin/checksec2111 /usr/bin/checksec

Давайте запустим checksec для утилиты просмотра содержимого каталогов (ls):

$ checksec --file=/usr/bin/ls<strong>RELRO      STACK CANARY   NX      PIE       RPATH   RUNPATH   Symbols    FORTIFY Fortified    Fortifiable  FILE</strong>Full RELRO   Canary found   NX enabled  PIE enabled   No RPATH  No RUNPATH  No Symbols    Yes  5    17       /usr/bin/ls

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

Первая строка это шапка таблицы, в которой перечислены различные свойства безопасности RELRO, STACK CANARY, NX и так далее. Вторая строка показывает значения этих свойств для бинарного файла утилиты ls.

Hello, бинарник!


Я скомпилирую бинарный файл из простейшего кода на языке С:

#include <stdio.h>int main(){printf(Hello World\n);return 0;}

Обратите внимание, что пока я не передал компилятору ни одного флага, за исключением -o (он не относится к делу, а просто говорит, куда выводить результат компиляции):

$ gcc hello.c -o hello$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=014b8966ba43e3ae47fab5acae051e208ec9074c, for GNU/Linux 3.2.0, not stripped$ ./helloHello World

Теперь запущу утилиту checksec для моего бинарника. Некоторые свойства отличаются от свойств

ls (для него я запускал утилиту выше):$ checksec --file=./hello<strong>RELRO      STACK CANARY   NX      PIE       RPATH   RUNPATH   Symbols     FORTIFY Fortified    Fortifiable   FILE</strong>Partial RELRO  No canary found  NX enabled  No PIE     No RPATH  No RUNPATH  85) Symbols    No  0    0./hello

Checksec позволяет использовать различные форматы вывода, которые вы можете указать с помощью опции --output. Я выберу формат JSON и сделаю вывод более наглядным с помощью утилиты jq:

$ checksec --file=./hello --output=json | jq{./hello: {relro: partial,canary: no,nx: yes,pie: no,rpath: no,runpath: no,symbols: yes,fortify_source: no,fortified: 0,fortify-able: 0}}

Анализ (checksec) и устранение (gcc) уязвимостей


Созданный выше бинарный файл имеет несколько свойств, определяющих, скажем так, степень его уязвимости. Я сравню свойства этого файла со свойствами бинарника ls (тоже указаны выше) и объясню, как это сделать с помощью утилиты checksec.

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

1. Отладочные символы


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

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

Сhecksec показывает, что отладочные символы присутствуют в моём бинарнике, но их нет в файле ls.

$ checksec --file=/bin/ls --output=json | jq | grep symbolssymbols: no,$ checksec --file=./hello --output=json | jq | grep symbolssymbols: yes,


То же самое может показать запуск команды file. Символы не удалены (not stripped).

$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=014b8966ba43e3ae47fab5acae051e208ec9074c, for GNU/Linux 3.2.0, <strong>not stripped</strong>

Как работает checksec


Запустим эту команду с опцией --debug:

$ checksec --debug --file=./hello

Так как утилита checksec это один длинный скрипт, то для его изучения можно использовать функции Bash. Выведем команды, которые запускает скрипт для моего файла hello:

$ bash -x /usr/bin/checksec --file=./hello

Особое внимание обратите на echo_message вывод сообщения о том, содержит ли бинарник отладочные символы:

+ readelf -W --symbols ./hello+ grep -q '\.symtab'+ echo_message '\033[31m96) Symbols\t\033[m ' Symbols, ' symbols=yes' 'symbols:yes,'

Утилита checksec использует для чтения двоичного файла команду readelf со специальным флагом --symbols. Она выводит все отладочные символы, которые содержатся в бинарнике.

$ readelf -W --symbols ./hello

Из содержимого раздела .symtab можно узнать количество найденных символов:

$ readelf -W --symbols ./hello | grep -i symtab

Как удалить отладочные символы после компиляции


В этом нам поможет утилита strip.

$ gcc hello.c -o hello$$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=322037496cf6a2029dcdcf68649a4ebc63780138, for GNU/Linux 3.2.0, <strong>not stripped</strong>$$ strip hello$$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=322037496cf6a2029dcdcf68649a4ebc63780138, for GNU/Linux 3.2.0, <strong>stripped</strong>

Как удалить отладочные символы во время компиляции


При компиляции используйте флаг -s:

$ gcc -s hello.c -o hello$$ file hellohello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=247de82a8ad84e7d8f20751ce79ea9e0cf4bd263, for GNU/Linux 3.2.0, <strong>stripped</strong>

Убедиться, что символы удалены, можно и с помощью утилиты checksec:

$ checksec --file=./hello --output=json | jq | grep symbolssymbols: no,

2. Canary


Canary (осведомители) это секретные значения, которые хранятся в стеке между буфером и управляющими данными. Они используются для защиты от атаки переполнения буфера: если эти значения оказываются изменены, то стоит бить тревогу. Когда приложение запускается, для него создаётся свой стек. В данном случае это просто структура данных с операциями push и pop. Злоумышленник может подготовить вредоносные данные и записать их в стек. В этом случае буфер может быть переполнен, а стек повреждён. В дальнейшем это приведёт к сбою работы программы. Анализ значений canary позволяет быстро понять, что произошёл взлом и принять меры.

$ checksec --file=/bin/ls --output=json | jq | grep canarycanary: yes,$$ checksec --file=./hello --output=json | jq | grep canarycanary: no,$Чтобы проверить, включен ли механизм canary, скрипт checksec запускает следующую команду:$ readelf -W -s ./hello | grep -E '__stack_chk_fail|__intel_security_cookie'

Включаем canary


Для этого при компиляции используем флаг -stack-protector-all:

$ gcc -fstack-protector-all hello.c -o hello$ checksec --file=./hello --output=json | jq | grep canarycanary: yes,

Вот теперь сhecksec может с чистой совестью сообщить нам, что механизм canary включён:

$ readelf -W -s ./hello | grep -E '__stack_chk_fail|__intel_security_cookie'2: 0000000000000000   0 FUNC  GLOBAL DEFAULT UND __stack_chk_fail@GLIBC_2.4 (3)83: 0000000000000000   0 FUNC  GLOBAL DEFAULT UND __stack_chk_fail@@GLIBC_2.4$

3. PIE


Включённое свойство PIE позволяет произвольно размещать в памяти исполняемый код независимо от его абсолютного адреса:

PIE (Position Independent Executable) исполняемый позиционно-независимый код. Возможность предсказать, где и какие области памяти находятся в адресном пространстве процесса играет на руку взломщикам. Пользовательские программы загружаются и выполняются с предопределённого адреса виртуальной памяти процесса, если они не скомпилированы с опцией PIE. Использование PIE позволяет операционной системе загружать секции исполняемого кода в произвольные участки памяти, что существенно усложняет взлом.

$ checksec --file=/bin/ls --output=json | jq | grep piepie: yes,$ checksec --file=./hello --output=json | jq | grep piepie: no,

Часто свойство PIE включают только при компиляции библиотек. В выводе ниже hello помечен как LSB executable, а файл стандартной библиотеки libc (.so) как LSB shared object:

$ file hellohello: ELF 64-bit <strong>LSB executable</strong>, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=014b8966ba43e3ae47fab5acae051e208ec9074c, for GNU/Linux 3.2.0, not stripped$ file /lib64/libc-2.32.so/lib64/libc-2.32.so: ELF 64-bit <strong>LSB shared object</strong>, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4a7fb374097fb927fb93d35ef98ba89262d0c4a4, for GNU/Linux 3.2.0, not stripped

Checksec получает эту информацию следующим образом:

$ readelf -W -h ./hello | grep EXECType:               EXEC (Executable file)

Если вы запустите эту же команду для библиотеки, то вместо EXEC увидите DYN:

$ readelf -W -h /lib64/libc-2.32.so | grep DYNType:               DYN (Shared object file)

Включаем PIE


При компиляции программы нужно указать следующие флаги:

$ gcc -pie -fpie hello.c -o hello

Чтобы убедиться, что свойство PIE включено, выполним такую команду:

$ checksec --file=./hello --output=json | jq | grep piepie: yes,$

Теперь у нашего бинарного файла (hello) тип сменится с EXEC на DYN:

$ file hellohello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb039adf2530d97e02f534a94f0f668cd540f940, for GNU/Linux 3.2.0, not stripped$ readelf -W -h ./hello | grep DYNType:               DYN (Shared object file)

4. NX


Средства операционной системы и процессора позволяют гибко настраивать права доступа к страницам виртуальной памяти. Включив свойство NX (No Execute), мы можем запретить воспринимать данные в качестве инструкций процессора. Часто при атаках переполнения буфера злоумышленники помещают код в стек, а затем пытаются его выполнить. Однако, если запретить выполнение кода в этих сегментах памяти, можно предотвратить такие атаки. При обычной компиляции с использованием gcc это свойство включено по умолчанию:

$ checksec --file=/bin/ls --output=json | jq | grep nxnx: yes,$ checksec --file=./hello --output=json | jq | grep nxnx: yes,

Чтобы получить информацию о свойстве NX, checksec вновь использует команду readelf. В данном случае RW означает, что стек доступен для чтения и записи. Но так как в этой комбинации отсутствует символ E, на выполнение кода из этого стека стоит запрет:

$ readelf -W -l ./hello | grep GNU_STACKGNU_STACK   0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10

Отключение NX


Отключать свойство NX не рекомендуется, но сделать это можно так:

$ gcc -z execstack hello.c -o hello$ checksec --file=./hello --output=json | jq | grep nxnx: no,

После компиляции мы увидим, что права доступа к стеку изменились на RWE:

$ readelf -W -l ./hello | grep GNU_STACKGNU_STACK   0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10

5. RELRO


В динамически слинкованных бинарниках для вызова функций из библиотек используется специальная таблица GOT (Global Offset Table). К этой таблице обращаются бинарные файлы формата ELF (Executable Linkable Format). Когда защита RELRO (Relocation Read-Only) включена, таблица GOT становится доступной только для чтения. Это позволяет защититься от некоторых видов атак, изменяющих записи таблицы:

$ checksec --file=/bin/ls --output=json | jq | grep relrorelro: full,$ checksec --file=./hello --output=json | jq | grep relrorelro: partial,

В данном случае включено только одно из свойств RELRO, поэтому checksec выводит значение partial. Для отображения настроек сhecksec использует команду readelf.

$ readelf -W -l ./hello | grep GNU_RELROGNU_RELRO   0x002e10 0x0000000000403e10 0x0000000000403e10 0x0001f0 0x0001f0 R  0x1$ readelf -W -d ./hello | grep BIND_NOW

Включаем полную защиту (FULL RELRO)


Для этого при компиляции нужно использовать соответствующие флаги:

$ gcc -Wl,-z,relro,-z,now hello.c -o hello$ checksec --file=./hello --output=json | jq | grep relrorelro: full,

Всё, теперь наш бинарник получил почётное звание FULL RELRO:

$ readelf -W -l ./hello | grep GNU_RELROGNU_RELRO   0x002dd0 0x0000000000403dd0 0x0000000000403dd0 0x000230 0x000230 R  0x1$ readelf -W -d ./hello | grep BIND_NOW0x0000000000000018 (BIND_NOW) 

Другие возможности checksec


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

Проверка нескольких файлов


Нет необходимости для каждого файла запускать отдельную команду. Можно запустить одну команду сразу для нескольких бинарных файлов:

$ checksec --dir=/usr/bin

Проверка процессов


Утилита checksec также позволяет анализировать безопасность процессов. Следующая команда отображает свойства всех запущенных программ в вашей системе (для этого нужно использовать опцию --proc-all):

$ checksec --proc-all

Вы также можете выбрать для проверки один процесс, указав его имя:

$ checksec --proc=bash

Проверка ядра


Аналогично вы можете анализировать уязвимости в ядре вашей системы.

$ checksec --kernel

Предупреждён значит вооружён


Подробно изучите свойства безопасности и попытайтесь понять, на что именно влияет каждое из них и какие виды атак это позволяет предотвратить. Checksec вам в помощь!



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Как мы весь интернет сканировали

20.06.2021 16:11:04 | Автор: admin

Всем привет! Меня зовут Александр и я пишу код для 2ip.ru. За добрую половину сервисов можно пинать меня, готов отбиваться. Cегодня я хочу немного рассказать про переделку одного нашего старого сервиса. Это конечно не "big data", но всё равно довольно большие объемы информации, поэтому думаю будет интересно.

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

Как это всегда работало? Мы ходили в Bing с большого пула адресов и парсили выдачу по специальному запросу. Да, решение так себе, но что было то было. Было, потому что бинг прикрутил гайки и мы решили всё это сделать по человечески.

Своя база

Что если взять и спарсить весь интернет? В общем то не проблема, но мы не Google и больших ресурсов для кролинга не имеем. Или имеем?

Есть сервер с 12 ядрами и 64 гигами памяти, а в арсенале MySQL, PHP, golang и куча всяких фреймворков. Очевидно, что благодаря горутинам можно достичь неплохих результатов. Golang быстр и требует минимум ресурсов. По базе вопросы, потянет ли это все обычный MySQL?

Пробуем.

Делаем прототип

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

Итак на моем диске CSV файл размером 5 ГБ, дело за малым, написать масс ресолвер, который будет читать строку за строкой, а на выход в STDOUT, отдавать пару "домен - IP адрес"

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

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

func main() {    file, err := os.Open("domains.txt")    if err != nil {        log.Fatal(err)    }    defer file.Close()    maxGoroutines := 500    guard := make(chan struct{}, maxGoroutines)    scanner := bufio.NewScanner(file)    for scanner.Scan() {        guard <- struct{}{}        host := scanner.Text()        go func(host string) {            resolve(host)            <-guard        }(host)    }    if err := scanner.Err(); err != nil {        log.Fatal(err)    }}

Суть в том, что мы можем набрать пул в 500 горутинов и непрерывно обрабатывать большое количество данных в единицу времени, подгружая равномерно все 12 ядер сервера.

Функция resolve опущена, но кратко это обычный ресолвер IP с выдачей результата в STDOUT. Обращаемся к DNS, получаем A записи, выдаем результат.

DNS

Прогуглив немного я понял, что большие DNS особо не лимитируют количество запросов с одного IP, но кто знает. Поэтому было принято решение поднять undbound из Docker.

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

Второй вариант Google DNS, тот который четыре восьмерки, оказался гораздо быстрее. У меня были опасения по лимитам в 500 запросов в секунду но по факту их нет.

Тестируем в localhost и на проде

Нельзя сказать что на тестовом ноутбуке граббер работал быстро. 500 горутинов машина не потянула, процесс падал через несколько секунд. Зато все кардинально поменялось на боевом сервере.

1000 горутинов упали на 12 ядрах, а вот 500 практически не грузили проц и работали стабильно. Мощность получилась на уровне ~2000 доменов в секунду.

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

В конечном счёте я оставил процесс в tmux и через трое суток получил CSV размером 10 Гб. Идём дальше.

Ура! Переходим к следующему шагу.

База данных

Я создал таблицу domain_ip, в которой всего два столбца домен и IP. Оба не уникальны, на один домен может приходиться несколько IP адресов.

IP - это обычный BIGINT domain - VARCHAR 255

Индексы

Очевидно, что выборка из 260 млн записей это довольно большая работа. Поэтому без индексов не обойтись, поиск у нас по IP адресу, значит его и индексируем.

20 минут импорта на тестовой машине и я понял что это фиаско, выборка работает медленно несмотря на индексы. 260 млн записей это очень много. Переходим к плану Б.

Партиципирование

Это метод разделения больших таблиц на мелкие и в дальнейшем уже обращение по нужному адресу сразу к конкретной таблице.

Я разделил весь пул IP адресов на 20 таблиц с шагом 200 млн. Получилось примерно так:

ALTER TABLE domain_ip PARTITION BY RANGE COLUMNS (ip)  (    PARTITION p0 VALUES LESS THAN (200000000),    PARTITION p1 VALUES LESS THAN (400000000),    PARTITION p2 VALUES LESS THAN (600000000),    PARTITION p3 VALUES LESS THAN (800000000),    PARTITION p4 VALUES LESS THAN (1000000000),    PARTITION p5 VALUES LESS THAN (1200000000),    PARTITION p6 VALUES LESS THAN (1400000000),    PARTITION p7 VALUES LESS THAN (1600000000),    PARTITION p8 VALUES LESS THAN (1800000000),    PARTITION p9 VALUES LESS THAN (2000000000),    PARTITION p10 VALUES LESS THAN (2200000000),    PARTITION p11 VALUES LESS THAN (2400000000),    PARTITION p12 VALUES LESS THAN (2600000000),    PARTITION p13 VALUES LESS THAN (2800000000),    PARTITION p14 VALUES LESS THAN (3000000000),    PARTITION p15 VALUES LESS THAN (3200000000),    PARTITION p16 VALUES LESS THAN (3400000000),    PARTITION p17 VALUES LESS THAN (3600000000),    PARTITION p18 VALUES LESS THAN (3800000000),    PARTITION p19 VALUES LESS THAN (4000000000),    PARTITION p20 VALUES LESS THAN (MAXVALUE) );

И как вы поняли это сработало, иначе зачем эта статья? :)

Импорт

Кто работал с MySQL знает, что вливать большие дампы данных это довольно долгая операция. За долгие годы работы я не нашел ничего лучше, чем импорт данных из CSV. Выглядит это примерно так:

LOAD DATA INFILE '/tmp/domains.csv' IGNORE INTO TABLE domain_ipFIELDS TERMINATED BY ',' LINES TERMINATED BY '\n'

Машина переваривает CSV размером ~10 Гб за 30 минут.

Финал

Как результат получился вот такой милый сервис. Выборка из ~300 миллионов записей происходит мгновенно на довольно скромном по нынешним меркам сервере. Оперативной памяти нужно под это всё порядка 8 Гб.

Теперь можно узнать например, что к IP 8.8.8.8 человечество прицепило 8194 домена, ну или придумайте сами ... ;-)

Спасибо за внимание.

Подробнее..

Второе интервью с разработчиком Reiser4 Эдуардом Шишкиным

24.05.2021 22:08:50 | Автор: admin

Недавно со мной связался Эдуард Шишкин и попросил опубликовать интервью (что я с радостью и делаю) в формате вопрос-ответ.
С первым интервью (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-летний опыт разработок, две файловые системы написанные "с нуля". И столько же утилит восстановления данных. А это очень много!


Подробнее..

Велосипед длиной в полжизни

25.05.2021 20:20:29 | Автор: admin
Вперёд, в будущее!Вперёд, в будущее!

Начало

Да, именно так: я начинал писать основу PHP движка в 2001-ом году.

Тогда всё было проще: каталог inc/, в нём header.php, footer.php, common.php.

Но это было скучно и неинтересно, надо было ещё больше фишек, которые я бы мог предложить заказчикам. Так появился раздел admin/. Но примерно в тоже время появился PHPNuke, это была бомба! Такой уровень кастомизации! Я понял, чтоничего подобного я предложить не смогу, но и по требованиям мой движок былкуда как проще, хотя позволял организовать каталог товаров, список статей, галерею. Несколько лет я дальше двигался по основной своей работе: администрирование Linux-серверов.

Но как-то мне предложили работу в фирме именно PHP-разработчиком. Я ознакомилсяс проектом, и меня порадовали две вещи:

1. Все шаблоны в своём формате.

2. И они вместе с настройками лежат в базе данных.

Это же прекрасно! Какая гибкость! Ну и пусть на открытие заглавной страницы уходит 50+ запросов!С таблиц, в которых и 100 строк бывает редко, MySQL делает выборки мгновенно.

От наследия той работы я до сих пор не могу избавиться: например меню в моейCMS строится именно на основании данных с БД, но есть кэширование. Так же до сих пор поддерживается мной придуманный формат шаблонов, хотя вряд ли когда-нибудь я им воспользуюсь.

Ещё с той работы я привнёс в свою работу Subversion: это было круто! Пара команд - и мой домашний репозиторий с рабочим синхронизирован за бесплатные 60 секунд через 8w180! А когда начальство говорит что я нифига не делал то легко подвести статистику добавленных/изменённых строк! Работал я тогда,как правило,сдельно

Продолжение

Так я "проспал" появление AJAX, появление ООП в PHP, хотя последнее я просто не воспринял: зачем, когда у тебя в inc/ теперь уже не три файла, а пять, но всего пять и всё работает?

И да, примерно в то время благодаря одному из своих друзей я поставил на основной сервер Gentoo. Это было круто! Совсем другой уровень управления сервером! Когда на основном сервере стоит и абсолютно правильно работает Gentoo - на админов всяких Редхатов и Дебианов смотришь известно как :)

А как программист я стагнировал :( Переломным моментом должен был стать сайт для моих друзей с продвинутым каталогом товаров: тогда количество костылей в catalog/index.phpпереполнило все мыслимые пределы. Там на несколько лет появилась строка

$input["list_id"];

И всё. Просто написал! Ничего ничему не присваивается, никак не обрабатывается!

Но я несколько лет не удалял эту строку, она просто была незаметна на фоне огромного спагетти кода подпёртого костылями.

И тут очень хороший человек предлагает для его сайта сделать весьма интересный функционал. Ладно, я готов к новым испытаниям. Я тогда не знал, что такое Битрикс... Специалисты по нему, увидев мой код, могут упасть в обморок: я писал исключительно прямыми запросами к базе данных через $DB->Query. Часто они бывали весьма многострочными, но это всё равно было лучше, чем использовать недоORM Битрикса. И да, сколько вечеров было проведено, пока мы с другим очень хорошим человеком разгребали почему штатная выгрузка с 1С не работает! И тогда был курьёзный случай: я уже в модуль ядра полез, чтобы логирование добавить чтобы узнать на каком именно элементе каталога стопорится выгрузка, коллега подходит и говорит: Игорь, это же нифига не английский!? И тут я понимаю, что это, блин, немецкий: функции и переменные в XML парсере Битрикса на немецком! А я по запарке даже и не заметил! Хоть раз в карьере пригодился язык, который я в школе и институте учил. Проект был выполнен, но сейчас, к сожалению, он оказался никому не нужен :(

Позднее, когда пара людей мне предложили развить интересный проект на Yii1, я понял,как много я упустил за эти годы! Но свою CMS я не трогал особо:и страшно и вроде как не нужно. Проект на Yii1 в итоге не взлетел, но это был бесценный опыт. И когда мне предложили сделать свой, достаточно серьёзныйпроект, с нуля я недолго раздумывал: Yii2. С базой данных у меня не было сомнений: MariaDB, ибо с MySQL я, будучи сисадмином, научился делать EXPLAIN, чтобы запрос вместо трёх минут выполнялся меньше секунды.

Прозрение

И тут я споткнулся об реальность: я же толком никогда ООП не использовал в PHP. Спасибо видеоурокам Дмитрия Елисеева и шаблону приложения от Vova07. За пару месяцев я написал CRUD'ы для админского раздела, разумеется используя миграции и RBAC, дальше самразобрался как сделать REST API, разбил всё на модули и так далее. Но сегодня не об этом.

В своей CMS всё так же несколько файлов в каталоге inc/. Для приличия переименовал вinclude/. Поломал обратную совместимость :( На сервере ln -s ./inc ./include, но даже полному идиоту понятно, что это нереальный костыль :( Собираю и раскидываю функции по include/lib_*, лезть в скрипты, касающиеся каталога, боязно. Но тут опять же спасибо Дмитрию Елисееву: его курс про микрофрэймворк стал определяющим: нафиг свой шаблонизатор, когда есть Twig? Какие ещё отдельные JS скрипты и CSS файлы, когда благодаря laravel-mix можнов пару команд собирать бандл? Причём вместо CSS использовать SASS, который для меня сталнебольшим, но всё же открытием, и я за минут двадцать все стили перевёл на него.

А тесты!.. Это отдельная тема. С начала своей карьеры как сисадмина я видел, что в руководствах часто между make и make install бывает make test. Как долго идёт ./configure с ключами и при этом много что тестируется, какие ещё тесты нужны? Но тут попробовал - и понравилось! Меняю что-то в ключевых классах, запускаю composer test - и как приятно видеть, что они проходят! А если не проходят, то сразу понятно, где я что поломал. К сожалению, связность в моей CMS очень сильная, TDD я попробовал, но этот подход при такой связности скорее замедляет разработку, чем помогает :(

В итоге решил переписать 100500 костылей под нормальную архитектуру.

Решение

Это было непросто. Особенно морально: сисадмин внутри меня даже не говорил - кричал:"Работает? Не трожь! Обратную совместимость поломать решил? Идиот, сам же будешьчинить!". Но жребий был брошен, Рубикон перейдён: начав с самого простого: модуля статей, я в итоге переписал все модули, даже модуль каталога товаров. Да, я кодом недоволен и сейчас: до чистого кода далеко. Но код ради кода - это не то, к чему я стремлюсь: например DI контейнер в такой простой задаче будет перебором. Хотя кроме DI контейнера можно многиепрактики привнести, например, использовать request, response, log, cache, да и сам контейнерпо PSR, но я пока не вижу смысла тащить такие зависимости в проект :)Ведь чем меньше зависимостей тем проект надёжнее. Но для миграций я добавил в проект Phinx, который за собой притянул symfony/console и фреймворк Сakephp. Первый грех было не использовать а с Сake я в итоге взял модули кэширования и логер: зачем в очередной раз писать свои костыли или тянуть зависимости если эти компоненты и так уже в проекте?

Итог

В итоге это был непростой путь, но я доволен результатом. Конечно, впереди ещё многое предстоит сделать, но уже сейчас я готов поделиться своими наработками с сообществом. Жаль, что заказчики не видят разницы между набором костылей и более чистым кодом, в который можно вносить изменения, не опасаясь выбить карту на которой весь костыльный домик держится. Но оно того стоило, однозначно!

Ах, да: https://github.com/crlam0/cms

Подробнее..
Категории: Linux , Php , Yii , Yii2 framework

Перевод Сеть в bitly Linux tc для минимизации издержек и забавы ради

02.06.2021 20:09:34 | Автор: admin

Представьте, что вы, например, bitly то есть очень большой сервис сокращения ссылок. И вот, вы хотите скопировать свои 150 ТБ сжатых данных с одного физического кластера на другой, новый. Чтобы сделать это, вы запускаете distcp из набора инструментов hadoop и рады тому, насколько быстро он работает. Но, несколько позже, вы уже совсем не радуетесь жалобам обычных пользователей веб-сайта и API-клиентов случаются ошибки, задерживаются ответы, а данные их дата-центра только запутывают. К старту курса о DevOps мы перевели материал о том, что делать, если вы, как и bitly, оказались в подобной ситуации.


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

Важной частью инфраструктуры bitly и основным инструментом команды Data Science и рабочей группы обслуживания операций и инфраструктуры (Ops/Infra) в течение довольно долгого времени был физический кластер hadoop набор утилит, библиотек и фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из сотен и тысяч узлов. Мы уже давно вынашивали идею подключения нового кластера, копирования и объединения данных старого кластера с данными нового.

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

  • bitly работает с огромными объёмами данных: на момент миграции кластер hadoop занимал более 150 ТБ дискового пространства сжатых потоковых данных, то есть данных, полученных в результате работы наших различных приложений. Объёмы таких данных продолжали увеличиваться в результате дополнительной обработки другими приложениями;

  • физически инфраструктура bitly располагается в центре обработки данных нашего партнёра. Она состоит из трёх физических видов шасси (приложения, хранилище и база данных), расположенных в ряд в смежных стойках. На момент написания этой статьи каждое шасси имело три физических гигабитных Ethernet-канала (каждый логически изолирован посредством организации сети VLAN) прямой канал, обратный канал и схему удалённого управления (для внеполосного управления серверными шасси). Каждое соединение после прохождения через ряд патч-панелей и коммутаторов подключается к нашим главным коммутаторам через стеклянное оптоволокно 10 Gb по звездообразной схеме сети;

  • инфраструктура bitly занимает значительные физические ресурсы (сотни физических серверных шасси), однако управлением такой сетевой инфраструктурой и топологией занимается наш партнёр в центре обработки данных. Другими словами, на большинстве уровней физического сетевого стека мы имеем крайне ограниченную видимость сетевых операций, не говоря уже об их контроле.

Вернёмся к нашей истории.

Для быстрого копирования данных с одного кластера на другой мы воспользовались инструментом distcp, поставляемом в комплекте с кластером hadoop. Говоря просто, инструмент distcp выдаёт задание программному фреймворку mapreduce (используемому для параллельных вычислений над очень большими наборами данных в компьютерных кластерах) на перемещение данных из одного кластера hdfs в другой при копировании узлов в режиме "многие ко многим". Инструмент distcp сработал быстро, и это нас порадовало.

Но тут сломался сервис bitly, и это не привело в восторг команду Ops/Infra.

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

Теперь нам нужно было решать сразу две противоречивые задачи: с одной стороны, надо было продолжать миграцию hadoop, а с другой устранить неполадки и понять, в чём же кроется наша сетевая проблема.

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

В новом кластере было больше узлов, значит, по идее, hadoop должен был работать быстрее.

Мы, кажется, осчастливили команду Data Science.

Но, к сожалению, поскольку кластер hadoop стал крупнее и быстрее, во время работы mapreduce на большее количество узлов стало передаваться большее количество данных, и это привело к непредвиденному эффекту:

Сервис bitly опять сломался, на этот раз очень серьёзно. Команда Ops/Infra была от этого не в восторге.

Первым импульсивным действием было вообще отрубить hadoop.

Но такое решение очень не понравилось команде Data Science.

Отключение кластера hadoop самое плохое из возможных решений (по последствиям может сравниться разве что с поломкой bitly), поэтому мы вернули кластер в состояние 1995 года, заставив все сетевые карты перейти на 100 Мбит/с (с 1 Гбит/с) с помощью команды ethtool -s eth1 speed 100 duplex full autoneg on. Теперь можно было спокойно подключить hadoop, но какой же медленной стала его работа!

Команда Data Science по-прежнему не выказывала признаков восторга.

И действительно, работа кластера была настолько "тормозной", что при вводе данных, выполнении запланированных заданий ETL (извлечения, преобразования и загрузки) и выдаче отчётов стали часто возникать сбои, постоянно срабатывали аварийные сигналы, будившие среди ночи членов команды Ops/Infra.

Надо ли говорить, как это не нравилось команде Ops/Infra!

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

Сделаем ещё одно небольшое отступление:

Что нам было доступно в bitly?

  • roles.json : список серверов (app01, app02, userdb01, hadoop01 и т. д.), ролей (userdb, app, web, monitoring, hadoop_node и т.д.), а также сведения об отображении серверов на роли (app01,02 -> app, hadoop01,02 -> hadoop_node и т. д.);

  • $datacenter/jsons/* : каталог, содержащий json-файл для каждого логического сервера с атрибутами, описывающими сервер, IP-адресами, именами, информацией конфигурирования и, что наиболее важно в нашей истории, расположением стоек.;

  • Linux : Linux.

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

Но команда Ops/Infra не проявляла признаков радости.

Её не устраивал синтаксис системы контроля сетевого трафика (Traffic Control, tc) в Linux, не говоря уже о совершенно неудобочитаемой документации. После напряжённого периода работы (с многочисленными проклятиями и разбиванием о стену клавиатур) мы смогли, наконец, создать не вызывающие отторжения работающие сценарии в tc. Были открыты ветви, написаны скрипты, выполнены развёртывания, проведены эталонные тестирования, и в результате было создано несколько тестовых узлов с таким кодом:

$ tc class show dev eth1class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b    cburst 1561bclass htb 1:10 root prio 0 rate 819200Kbit ceil 819200Kbit burst 1433b     cburst 1433bclass htb 1:20 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b     cburst 1561b$ tc filter show dev eth1filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16filter parent 1: protocol ip pref 49129 u32 filter parent 1: protocol ip pref 49129 u32 fh 817: ht divisor 1 filter parent 1: protocol ip pref 49129 u32 fh 817::800 order 2048 key     ht 817 bkt 0 flowid 1:10     match 7f000002/ffffffff at 16filter parent 1: protocol ip pref 49130 u32 filter parent 1: protocol ip pref 49130 u32 fh 816: ht divisor 1 filter parent 1: protocol ip pref 49130 u32 fh 816::800 order 2048 key     ht 816 bkt 0 flowid 1:20     match 7f000003/ffffffff at 16<snipped>$ tc qdisc showqdisc mq 0: dev eth2 root qdisc mq 0: dev eth0 root qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100     direct_packets_stat 24

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

class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit burst 1561b cburst 1561b

Каждый класс это потолок пропускной способности исходящего трафика, агрегированного по всем подписанным на этот класс фильтрам.

Каждый фильтр это конкретное правило для конкретного IP (к сожалению, каждый IP выводится в шестнадцатеричном формате), поэтому фильтр:

filter parent 1: protocol ip pref 49128 u32 filter parent 1: protocol ip pref 49128 u32 fh 818: ht divisor 1 filter parent 1: protocol ip pref 49128 u32 fh 818::800 order 2048 key     ht 818 bkt 0 flowid 1:20     match 7f000001/ffffffff at 16

можно интерпретировать как "subscribe hadoop14 to the class 1:20", где "7f000001" можно интерпретировать как IP для hadoop14, а "flowid 1:20" класс для подписки. Затем запускаем команду qdisc, формирующую более или менее активную очередь для устройства eth1. Данная очередь по умолчанию помещает любой хост, не определённый в фильтре класса, в класс 1:100:

qdisc htb 1: dev eth1 root refcnt 9 r2q 10 default 100 direct_packets_stat 24

В такой конфигурации любой хост (hadoop или другой), находящийся в одной стойке с конфигурируемым хостом, получает фильтр, назначенный классу "1:10", разрешающий скорость передачи до ~800 Мбит/с для класса в целом. Аналогичным образом для предопределённого списка ролей, считающихся "ролями приоритетных узлов", создаётся фильтр по тому же правилу "1:100". Такие узлы выполняют довольно важные задачи, например запускают сервисы hadoop namenode или jobtracker, а также наши узлы мониторинга. Любой другой хост hadoop, не находящийся в той же стойке, подключается к классу "1:20", ограниченному более консервативным классом ~200 Мбит/с.

Как было сказано выше, любой хост, не определённый в фильтре, попадает в класс по умолчанию для eth1 qdisc, то есть в класс "1:100". Как это выглядит на практике? Вот хост, подпадающий под действие правила "1:100":

[root@hadoop27 ~]# iperf -t 30 -c NONHADOOPHOST------------------------------------------------------------Client connecting to NONHADOOPHOST, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 35897 connected with NONHADOOPHOST port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.1 sec   735 MBytes   205 Mbits/sec

Теперь при подключении к другому хосту, расположенному в той же стойке или подпадающему под правило "1:10":

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER------------------------------------------------------------Client connecting to CABINETPEER, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39016 connected with CABINETPEER port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  2.86 GBytes   820 Mbits/sec

Что произойдёт при подключении к двум серверам, подпадающим под правило "1:10"?

[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER1------------------------------------------------------------Client connecting to CABINETPEER1, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 39648 connected with CABINETPEER1 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.47 GBytes   421 Mbits/sec[root@hadoop27 ~]# iperf -t 30 -c CABINETPEER2------------------------------------------------------------Client connecting to 10.241.28.160, TCP port 5001TCP window size: 23.2 KByte (default)------------------------------------------------------------[  3] local hadoop27 port 38218 connected with CABINETPEER2 port 5001[ ID] Interval       Transfer     Bandwidth[  3]  0.0-30.0 sec  1.43 GBytes   408 Mbits/sec

Трафик уменьшится вдвое? Похоже на правду. Даже лучше стало относительно проще отслеживать тренды данных, анализируя статистические данные, выводимые на наши сервисы трендов:

$ /sbin/tc -s class show dev eth1 classid 1:100class htb 1:100 root prio 0 rate 204800Kbit ceil 204800Kbit     burst 1561b cburst 1561b Sent 5876292240 bytes 41184081 pkt (dropped 0, overlimits 0 requeues 0) rate 3456bit 2pps backlog 0b 0p requeues 0 lended: 40130273 borrowed: 0 giants: 0tokens: 906 ctokens: 906

После тестирования мы проверили хосты hadoop, подняв их скорости до первоначальных 1Gb после применения ролей traffic control. После всех описанных действий кластер hadoop вновь обрёл достаточно высокую производительность.

Мы осчастливили команду Data Science.

Команда Ops/Infra смогла приступить к устранению неполадок и поиску решений, при этом спокойно спать по ночам, зная, что сервис bitly будет вести себя нормально.

Мы осчастливили и команду Ops/Infra.

Выводы:

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

  • Не загоняйте себя в трудные ситуации: изучите все нюансы среды, в которой будете работать. В данном случае нам следовало лучше понять и оценить масштабы миграции hadoop и её возможные последствия.

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

  • Linux: Linux

И последнее

Эта история хорошая иллюстрация "закона Мерфи для девопсов":

Закон Мёрфи для девопсов: "Если что-то может пойти не так, значит, что-то уже идёт не так, просто Nagios ещё не предупредил".

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Вкусовщина Я не могу работать на MacBook Pro 16

05.06.2021 00:21:43 | Автор: admin

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

Я - простой разработчик, пишу на Java/Kotlin, бэкэнд. Ранее работал на Windows (было давно и не продолжительное время), потом пересел на Linux по ряду причин. Безвылазно на Linux 7 лет, вообщем с системой работал около 16. В один прекрасный день мне довелось устроиться в компанию, где Linux для пользователей не то чтобы под запретом, скорее просто нежелательно (читать с приставкой - крайне). Что из этого вышло....

Долгое время я был свободным человеком, почти без обязательств, и выбор на чем работать был только за мной, ну или за моим карманом и жадностью. Последний сетап был уж достаточно странным: Dell Precision 7540 (Xeon E-2286M, 48GB RAM, 2x512GB ssd m.2, 256GB SSD m.2, GF T2000), 2 монитора Dell p2418d, док станция Dell TB16, клавиатура Apple Magic Keyboard with numeric, мышь Apple Magic Mouse 2. Вообщем этакие набор кулл хацкера с комплексом ущербного мозга (ну может хоть сетап будет помогать писать гомнокод получше).

Конечно все это собиралось не за один день и покупалось на кровные с ебея и прочих мест всякими мутными схемами. До этого апгрейда я спокойно (ну насколько это можно) сидела на Fedora, но на этом железе начались дикие проблемы и пришлось установить Ubuntu, на которую был сертифицирован ноутбук (да, он еще и на RedHat сертифицирован, но там совсем беда). В общем настраивать все это дело было таким себе удовольствием, особенно клавиатуру и мышь (то установи, тут скрипты напиши), страшно было потом систему apt upgrade, про переустановку вообще молчу, но все же приходилось и каждый раз боль-страдания-красные-глаза-сатисфакция.

Мне очень нравилась по качеству клавиатура от Apple, пальцы летали на ней, когда все продавал даже думал оставить ее. Зато вот убунту меня иногда раздражала какими-либо проблемами: то блютуз глючит, то апдейт прилетит после которого кучка ошибок, ну а про переустановки я уже упоминал, благо заготовки были на такие случаи со временем. В трудные моменты я подумывал о смене своего Dell на MacBook. Мотивация была такая: этож тот же *nix, только стабильней, комфортабельней и вообще этожэппл.

В один прекрасный день я решил, что хватит работать удаленно и нужно уезжать из своего городка в цивилизацию. Распродал все, приехал в другой город, устроился в компанию и мне выдали MacBook 16 Pro. Думаю: вот оно походу пришло, что хотел, теперь-то я буду работать на нормальной системе и клава вроде такая же..... но не тут-то было.

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

Оценил: Экран, тачпад, колонки. Эти компоненты просто вышка без всяких. Лучше пока еще не видел в ноутбуках.

Через пару дней уже завыл, так как хоткеи ну совсем не понимал, а вот эти Fn и ~..... ну ладно Fn, но ~ засунуть в такое интересное место + Enter: мизинец постоянно нажимал что угодно, но не Enter. Ну ладно думаю, привыкну... Прошла неделя, вроде даже научился печатать на этой клаве, но не Intelleji Idea. Да, я понимаю, что там другая раскладка, но вот я постоянно нажимал первое время Command + Q.... ну вы поняли что происходило и как печально было мое лицо.

Еще через время начал замечать, что чего-то не хватает и понял: открыть меню File я не могу, отобразить ветки Git тоже... Нужно значит что-то настраивать под себя, т.е. добавлять хоткеи. Ну ладно может быть и добавил бы, но вот беда, чтобы нажать условный F10, нужно нажать Fn, а делит... ну вы знаете как он устроен. Т.е. вместо 3 клавиш нужно нажимать 4, некоторые сочетания не просто выполнить даже если посещал пальцевую гимнастику (если такая есть). Молчу уже про конфликты некоторых хоткеев с системными. Но главный поинт такой, что вместо того, чтобы эффективно работать я должен воевать со своими пальцами и чудесными сочетаниями клавиш в виду отсутствия F, del, PgDown, PgUp и т.д.

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

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

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

Но как разработчик я себя чувствую лучше на Linux, правда вот клавиатуры (Apple Magic Keyboard with num pad) не хватает (хотя на моем текущем Honor-е клава по нажатию хороша), ну и тач бы еще маковский.

Подробнее..

Перевод Собираем и устанавливаем свою Linux-систему на микроконтроллер STM32MP1

09.06.2021 10:16:43 | Автор: admin

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

В этой статье мы автоматизируем процесс сборки и установки Linux-системы на микроконтроллер STM32MP157-DK2. ОС будет обладать минимальной функциональностью, но зато мы соберём из исходников собственную систему. А поможет нам в этом Buildroot система сборки Linux-дистрибутивов.

Что такое Buildroot?


Сначала вспомним, что Linux-система состоит из достаточно большого количества разных компонентов. Так как мы здесь говорим про embedded-платформы, выделим следующие компоненты:

  1. Загрузчик (обычно для архитектуры ARM это U-Boot): выполняет инициализацию HW, загружает ядро Linux и стартует его.
  2. Собственно, само ядро, управляющее процессами и памятью, содержащее планировщик, файловые системы, сетевой стек и, конечно, все необходимые драйвера для вашей аппаратной платформы.

  3. Пользовательские библиотеки и приложения из open source экосистемы: командные оболочки, библиотеки для работы с графикой, сетью, шифрованием и так далее.

  4. Внутренние пользовательские библиотеки и приложения, реализующие какую-то свою бизнес-логику.

Собрать все эти компоненты воедино мы можем двумя способами:

  1. Использовать готовый бинарный дистрибутив, например от Debian, Ubuntu или Fedora.

    Некоторые из этих дистрибутивов поддерживают архитектуру ARMv7. Основное преимущество этого решения в том, что оно простое: эти бинарные дистрибутивы знакомы большинству пользователей Linux-систем, они имеют красивую и простую в использовании систему управления пакетами, все пакеты предварительно скомпилированы, поэтому нашей цели можно достичь очень быстро. Однако собранные таким образом системы обычно сложно кастомизировать (компоненты уже созданы, поэтому вы не можете легко изменить их конфигурацию в соответствии с вашими потребностями) и сложно оптимизировать (с точки зрения объёма занимаемой памяти или времени загрузки).

  2. Использовать систему сборки, например,Buildroot илиYocto/OpenEmbedded.

    Они позволяют собрать Linux-систему непосредственно из исходного кода. А это означает, что систему будет легко оптимизировать и кастомизировать под свои нужды. Конечно же, этот способ намного сложнее, а на компиляцию кода придётся потратить немало процессорного времени.

Мы выбираем второй способ. В этой статье используем Buildroot, потому что с этой системой сборки достаточно просто разобраться и она подходит для embedded-платформ.

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

Важно отметить, что Buildroot не поставляется с исходными кодами Linux, с U-Boot или с другими компонентами. Он всего лишь содержит набор скриптов и инструкций, описывающих, какой исходный код загружать и какие настройки использовать при сборке.

Как собрать Linux-систему с Buildroot?


Начнём с установки самой системы Buildroot, а потом перейдём к её настройке:

git clone git://git.buildroot.net/buildrootcd buildroot

Обычно настройка Buildroot делается с помощью команды make menuconfig, которая позволяет указать необходимые опции для вашей системы. Но мы вместо этого используем свою конфигурацию, которую мы создали заранее специально для STM32MP157-DK2. Она находится в моём репозитории.

git remote add tpetazzoni https://github.com/tpetazzoni/buildroot.gitgit fetch tpetazzonigit checkout -b stm32mp157-dk2 tpetazzoni/2019.02/stm32mp157-dkА теперь дадим Buildrootу команду использовать нашу конфигурацию.make stm32mp157_dk_defconfig

Мы могли бы сразу приступить к сборке, так как эта конфигурация работает нормально. Но здесь я хочу показать, как можно изменить конфигурацию и ускорить сборку. Мы изменим всего один параметр. Для этого запустим утилиту menuconfig (она встроена в Buildroot). Если кто-то из вас уже настраивал ядро Linux, этот инструмент должен быть вам интуитивно понятен, поскольку это просто утилита для настройки.

make menuconfig

Если команда не сможет работать из-за отсутствия библиотеки ncurses, установите пакет libncurses-dev или ncurses-devel (точное название пакета будет зависеть от версии Linux ОС, на которой вы запускаете Buildroot). Библиотека ncurses предназначена для управления вводом-выводом на терминал.

Успешно выполнив menuconfig, перейдём в подменю Toolchain. По умолчанию в Toolchain Type выбрана опция . Нужно изменить её на , нажав ENTER.

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


Выходим из menuconfig и сохраняем изменения. Теперь пришло время поработать с командой make. Я люблю всё логировать, поэтому она будет выглядеть вот так:

make 2>&1 | tee build.log

На этом этапе система сборки Buildroot проверит наличие всех необходимых пакетов. Если чего-то не обнаружит, то выполнение команды прервётся. Если это произойдёт, на сайте Buildroot посмотрите раздел System requirements > Mandatory packages и установите все необходимые зависимости. После этого можно запускать команду заново.

На моей машине команда make работала 10 минут. После сборки появится набор каталогов и файлов (самое интересное лежит в output/images):

  • output/images/zImage: здесь лежит ядро Linux;

  • output/images/stm32mp157c-dk2.dtb: блоб-файл дерева устройств (Device Tree Blob);
  • output/images/rootfs.{ext4,ext2}: файл-образ корневой файловой системы ext4, которая на сегодняшний день является самой популярной;

  • output/images/u-boot-spl.stm32: загрузчик первой стадии;

  • output/images/u-boot.img: загрузчик второй стадии;

  • output/images/sdcard.img: финальный образ для SD-карты, сгенерированный на основе предыдущих образов.

Прошивка и тестирование системы


Запишем sdcard.img на карту microSD:

sudo dd if=output/images/sdcard.img of=/dev/mmcblk0 bs=1M conv=fdatasync status=progress

Не забудьте проверить, что в вашей системе карта microSD определяется как /dev/mmcblk0 (и на всякий случай предупреждаю: после того, вы запишете туда образ, вся информация на этой карточке будет затёрта)!

Подключите карту к микроконтроллеру.

Соедините USB-кабелем ваш компьютер и micro-USB разъём с надписью ST-LINK CN11 на плате. Ваша машина должна распознать устройство с именем /dev/ttyACM0, через которое вы сможете получить доступ к последовательному порту платы. Установите на свой компьютер и запустите программу для общения с последовательным портом. Лично мне очень нравится picocom:

picocom -b 115200 /dev/ttyACM0

Он подходит для embedded-систем, так как занимает минимальный объём памяти (менее 20 КБ) и имеет подробную документацию.

Наконец, включите плату, воткнув кабель USB-C в разъём PWR_IN CN6. Затем на последовательный порт начнут приходить сообщения. Нам важно, что в конце появится приглашение залогиниться в системе Buildroot. Можно войти в систему с пользователем root, пароль вводить не нужно.


Этапы загрузки системы и вход


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

U-Boot SPL 2018.11-stm32mp-r2.1 (Apr 24 2019  10:37:17 +0200)

Это сообщение от загрузчика первой стадии: код, содержащимся в файле u-boot-spl.stm32 скомпилирован как часть загрузчика U-Boot. Его непосредственно загружает STM32MP157. Загрузчик первой стадии должен быть достаточно маленьким, чтобы поместиться во внутреннюю память STM32MP157.

U-Boot 2018.11-stm32mp-r2.1 (Apr 24 2019  10:37:17 +0200)

Это сообщение от загрузчика второй стадии, который был выгружен из внутренней памяти устройства во внешнюю память загрузчиком первой стадии. Загрузчик второй стадии это файл u-boot.img, который также является частью загрузчика U-Boot.

Retrieving file: /boot/zImageRetrieving file: /boot/stm32mp157c-dk2.dtb

Эти сообщения печатает загрузчик второй стадии: мы видим, что он загрузил образ ядра Linux (файл zImage) и блоб дерева устройств (файл stm32mp157c-dk2.dtb), описывающий нашу аппаратную платформу. Хорошо, U-Boot загрузил оба файла в память: теперь он готов к запуску ядра Linux.

Starting kernel ...Это последнее сообщение U-Boot, после этого управление передаётся ядру.[  0.000000] Booting Linux on physical CPU 0x0[  0.000000] Linux version 4.19.26 (thomas@windsurf) (gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11 (arm-rel-8.26))) #1 SMP PREEMPT Wed Apr 24 10:38:00 CEST 2019

И сразу появляются первые сообщения ядра Linux, показывающие версию Linux и дату/время сборки. Далее идут другие, не слишком интересные сообщения Нам нужно дождаться вот этого:

[  3.248315] VFS: Mounted root (ext4 filesystem) readonly on device 179:4.

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

Starting syslogd: OK[...]Welcome to Buildrootbuildroot login:

И вот, наконец, появляется то самое сообщение от Buildroot с просьбой залогиниться.

После входа в систему вы получите доступ к командной оболочке Linux. Введя команду ps, можно посмотреть список процессов, команда ls/ покажет содержимое корневой файловой системы и так далее.

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

echo 255 > /sys/class/leds/heartbeat/brightnessecho 0 > /sys/class/leds/heartbeat/brightness

Как сделать это с нуля?


Углубляемся в основы конфигурирования Buildroot


В начале статьи мы говорили про настройку и оптимизацию конфигурации Buildroot. По идее, для этого нужно сначала изучить основы конфигурирования в этой системе. Поэтому вернёмся в прошлое к команде make menuconfig.

В меню Target options выбрана архитектура ARM Little Endian, а в Target Architecture Variant указан Cortex-A7. На этом процессоре как раз построен наш микроконтроллер.

В меню Build options используем все значения по умолчанию.

Как я писал выше, в меню Toolchain вместо кросс-компилятора по умолчанию был выбран пункт <External toolchain>.

В меню System configuration мы произвели следующие изменения:

  1. Оверлей-каталоги корневой файловой системы определены как board/stmicroelectronics/stm32mp157-dk/overlay/. Эта опция сообщает Buildroot, что содержимое этого каталога должно быть скопировано в корневую файловую систему в конце сборки. Такой подход позволяет добавлять собственные файлы в корневую файловую систему.

  2. Для пользовательских скриптов, запускаемых после создания образов файловой системы, задано значение support/scripts/genimage.sh, а для параметра Extra arguments, передаваемого в пользовательские скрипты, задано значение -c board/stmicroelectronics/stm32mp157-dk/genimage.cfg. Это означает, что Buildroot должен вызвать скрипт genimage.sh в самом конце сборки: его цель сгенерировать финальный образ для SD-карты, который мы уже использовали.

В меню Kernel мы выбрали версию Linux и путь для конфигурации ядра:

  1. Мы загрузили исходники ядра Linux с Github с помощью макроса Buildroot под названием github. В соответствии с выбранной версией (v4.19-stm32mp-r1.2), Buildroot пошёл в репозиторий (https://github.com/STMicroelectronics/linux/) и загрузил оттуда ядро.

  2. Мы указали путь для конфигурации ядра: board/stmicroelectronics/stm32mp157-dk/linux.config. Конфигурацию ядра также можно кастомизировать для ваших нужд (эта тема выходит за рамки данной статьи).

  3. Мы включили опцию <Build a Device Tree Blob (DTB)> и записали в In-tree Device Tree Source file names имя нашего файла stm32mp157c-dk2. И тогда Buildroot сможет сформировать и использовать дерево устройств именно для нашей платформы.

  4. Мы установили для Install kernel image значение </boot in target>, поэтому образ ядра и дерево устройств будут находится в каталоге/bootкорневой файловой системы. U-Boot будет загружать их как раз оттуда.

В меню Target packages оставили значения по умолчанию: активен только пакет BusyBox. BusyBox очень популярный инструмент для embedded-платформ: это легковесная альтернатива Linux shell и другим инструментам командной строки (cp, mv, ls, vi, wget, tar). Для нашей системы нам хватит одного BusyBox!

В меню Filesystem images активировали ext2/3/4root filesystem и выбрали ext4. Эта файловая система отлично подходит для SD-карт.

Теперь в меню Bootloaders активируем U-Boot, для которого выполняем следующий набор действий:

  1. Загружаем U-Boot из репозитория https://github.com/STMicroelectronics/u-boot.git с Git-тегом v2018.11-stm32mp-r2.1

  2. U-Boot используем с предустановленной конфигурацией stm32mp15_basic, которую мы указываем для нашей платы с помощью defconfig.

  3. Вообще, эта конфигурация предполагает использование сторожевого таймера STM32. Но в нашей минималистичной версии Linux его нет. Поэтому мы пойдём в файл board/stmicroelectronics/stm32mp157-dk/uboot-fragment.config и отключим сторожевой таймер для текущей конфигурации. Если мы захотим расширить возможности нашей Linux-системы и добавить его, то использование таймер нужно вновь разрешить.

  4. Подменю U-Boot binary format: тут нужно предупредить Buildroot, что для загрузчика второй стадии должен быть создан образ u-boot.img, и именно его нужно будет поместить в output/images.

  5. Мы также сообщаем Buildroot, что на базе нашей конфигурации для U-Boot будет собран загрузчик первой стадии (файл spl/u-boot-spl.stm32). Его тоже нужно будет разместить в output/images.

  6. В окружение U-Boot мы добавляем опцию DEVICE_TREE=stm32mp157c-dk2. Она понадобится в процессе сборки U-Boot, чтобы использовать дерево устройств именно для нашей платформы.

  7. В меню Host utilities мы подключаем пакет genimage.

Вся эта конфигурация сохраняется в простом текстовом файле configs/stm32mp157_dk_defconfig, который мы загружали изначально при запуске make stm32mp157_dk_defconfig.

Углубляемся в процесс сборки Buildroot


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

  1. Загрузка и установка компилятора с веб-сайта ARM и установка библиотек C и C ++ на нашу корневую файловую систему.

  2. Загрузка исходного кода ядра Linux из репозитория STMicroelectronics, сборка ядра в соответствии с нашей конфигурацией, размещение zImage и stm32mp157c-dk2.dtb в каталоге output/images, размещение корневой файловой системы в каталоге /boot. Кроме того, на этом этапе происходит установка модулей ядра в корневую файловую систему.

  3. Загрузка исходного кода U-Boot из репозитория STMicroelectronics, его сборка в соответствии с нашей конфигурацией, размещение u-boot-spl.stm32 u-boot.img в каталоге output/images.

  4. Загрузка исходного кода Busybox с официального сайта, его сборка в соответствии с нашей конфигурацией и установка в корневую файловую систему.

  5. Копирование содержимого оверлей-каталогов в корневую файловую систему.

  6. Создание ext4-образа корневой файловой системы и его установка в output/images/rootfs.ext4

  7. Вызов скрипта genimage.sh, который сгенерирует образ для SD-карты, output/images/sdcard.img

Теперь давайте посмотрим на файл board/stmicroelectronics/stm32mp157-dk/genimage.cfg, который советует утилите genimage, как нужно правильно генерировать образ для SD-карты:

image sdcard.img {hdimage {gpt = true}partition fsbl1 {image = u-boot-spl.stm32}partition fsbl2 {image = u-boot-spl.stm32}partition uboot {image = u-boot.img}partition rootfs {image = rootfs.ext4partition-type = 0x83bootable = yessize = 256M}}

Какие конкретно указания даны в этом скрипте:

  1. Создать файл sdcard.img

  2. Этот файл должен содержать несколько разделов в соответствии с таблицей GPT partition table. Это нужно, чтобы встроенный ROM микроконтроллера STM32MP157 смог найти загрузчика первой стадии.

  3. Два первых раздела должны называться fsbl1 и fsbl2. Там должен храниться сырой бинарный код загрузчика первой стадии (отмечу, что в разделах не установлено никакой файловой системы). В коде ROM, встроенном в STM32MP157, жёстко прописано: нужно искать загрузчик первой стадии в первых двух разделах с именами, начинающимися с fsbl.

  4. Третий раздел (тоже без файловой системы) с именем uboot, по аналогии с предыдущим пунктом, хранит сырой бинарный файл загрузчика второй стадии. Действительно, загрузчик первой стадии должен найти загрузчика второй стадии в третьем разделе SD-карты (это определено в конфигурации U-Boot и может быть при необходимости изменено ).

  5. Четвёртый раздел содержит образ файловой системы ext4, созданный Buildroot. Этот образ фактически является нашей корневой файловой системой, вместе с BusyBox, стандартными библиотеками C/C ++, а также файлом-образом ядра Linux и блоб-файлом дерева устройств.

Последний раздел помечен как загрузочный (bootable). Это важно, потому что конфигурация U-Boot для аппаратной платформы STM32MP157 по умолчанию следует концепции U-Boot Generic Distro Concept. При загрузке U-Boot будет искать раздел, помеченный как загрузочный, а затем внутри файловой системы, содержащейся в этом разделе, искать файл /boot/extlinux/extlinux.conf, чтобы узнать, как загрузить систему.

Файл extlinux.conf находится внутри оверлей-каталога нашей файловой системы (board/stmicroelectronics/stm32mp157-dk/overlay/boot/extlinux/extlinux.conf), в корневой файловой системе он будет определяться как /boot/extlinux/extlinux.conf и U-Boot легко найдёт его.

Вот что внутри этого файла:

label stm32mp15-buildrootkernel /boot/zImagedevicetree /boot/stm32mp157c-dk2.dtbappend root=/dev/mmcblk0p4 rootwait

Таким образом мы говорим U-Boot, чтобы он загружал образ ядра из /boot/zImage, дерево устройств из /boot/stm32mp157c-dk2.dtb. А строка root=/dev/mmcblk0p4 rootwait должна быть передана ядру Linux во время загрузки. Именно в этом выражении (root=/dev/mmcblk0p4) хранится информация о том, где находится корневая файловая система.

Итак, сформулируем этапы загрузки собранной Linux-системы на нашей аппаратной платформе с учётом новых подробностей:

  1. Встроенный в STM32MP157 ROM ищет разделы GPT, чьи имена начинаются с fsbl. Если успешно, то загружает их содержимое во внутреннюю память STM32 и запускает загрузчик первой стадии.

  2. В соответствии с хардкодом, он обязан загрузить из третьего раздела SD-карты загрузчика второй стадии. Так, загрузчик первой стадии инициализирует внешнюю RAM, грузит в неё загрузчика второй стадии и стартует его.

  3. Загрузчик второй стадии выполняет ещё одну инициализацию, а затем ищет раздел, помеченный как загрузочный (bootable). Он обнаруживает, что таковым является четвёртый раздел. Он загружает файл /boot/extlinux/extlinux.conf, благодаря которому узнаёт, где расположены ядро и дерево устройств. Он загружает их и запускает ядро с аргументами, указанными всё в том же файле extlinux.conf.

  4. Ядро Linux работает до момента монтирования корневой файловой системы, расположение которой указано в параметре root=/dev/mmcblk0p4. После монтирования корневой файловой системы ядро запускает первый пользовательский процесс.

  5. В данном случае первый пользовательский процесс это /sbin/init (спасибо, BusyBox!). Он стартует несколько служб, а потом приглашает пользователя войти (ввести логин).

P.S. Вы можете найти исходный код для Buildroot, использованный в этой статье, вот здесь.



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Баги ради науки как Университет Миннесоты внедрял баги в код Linux

16.06.2021 10:13:29 | Автор: admin


Грег Кроа-Хартман, ответственный за сопровождение стабильных релизов ядра, в начале апреля запретил Университету Миннесоты (УМ) вносить изменения в код Linux. Университет Миннесоты по-видимому, всё это время сознательно вносил вредоносные изменения в код проекта. Развязка наступила после патча к механизму авторизации NFSv4, который не прошел проверку двух профильных разработчиков. Так выглядел тот самый патч.

diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.cindex 5f42aa5fc612..eb52eebb3923 100644--- a/net/sunrpc/auth_gss/auth_gss.c+++ b/net/sunrpc/auth_gss/auth_gss.c@@ -848,7 +848,8 @@ gss_pipe_destroy_msg(struct rpc_pipe_msg *msg)warn_gssd();gss_release_msg(gss_msg);}-gss_release_msg(gss_msg);+if (gss_msg)+gss_release_msg(gss_msg);}static void gss_pipe_dentry_destroy(struct dentry *dir,--2.25.1

Ирония однако заключается в том, что спорный проект, который привел к потере доверия к Университету Миннесоты, изначально был направлен на повышение безопасности Linux. В университете с августа 2020 г ассистент профессора Kangije Lu и аспирант Qjushi Wu работали над статьёй под названием On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits. Под термином Open-Source Software имеется в виду ядро Linux.

Авторам Hypocrite Commits удалось внести в код ядра изменения, содержащие в скрытом виде уязвимость вида обращение после освобождения памяти. Статья была принята на 42-м симпозиуме IEEE по безопасности и конфиденциальности, но уже 26-го апреля Qjushi Wu и Kangije Lu отозвали своё участие в мероприятии. В письме они выражают своё сожаление по поводу случившегося и просят прощения комитету за доставленные неудобства.

We now understand that it was inappropriate and hurtful to the community to make it a subject of our research, and to waste its effort reviewing these patches without its knowledge or permission.

Исследование было поддержано со стороны National Science Foundation и содержало гарантии того, что ни один баг не попадет в исходный код Linux. Тем не менее, именно это и произошло в итоге. Однако миннесотовцы не остановились на достигнутом и решили пойти дальше, стремясь в этот раз протащить новую серию уязвимых патчей под видом нового статического анализатора кода. Развязка наступила 6-го апреля, когда Грег Кроа-Хартман назвал вещи своими именами.

Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way.

This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university...

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

Излишне напоминать о том, что у разработчиков ядра и так достаточно проблем со спонтанными ошибками, следовательно поэтому патчи с намеренными ошибками явно нежелательны. Кроа-Хартман сказал, что все патчи, поступающие от @umn.edu отныне подлежат отмене, так как то, что они делают, является преднамеренным вредоносным поведением, неприемлемо и совершенно неэтично.

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

On Wed, Apr 21, 2021 at 02:56:27AM -0500, Aditya Pakki wrote:

Greg, I respectfully ask you to cease and desist from making wild accusations that are bordering on slander.

These patches were sent as part of a new static analyzer that I wrote and it's sensitivity is obviously not great. I sent patches on the hopes to get feedback. We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear.

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

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

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

Our community does not appreciate being experimented on, and being tested by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.

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

Технический Консультационный Совет Linux Foundation направил сообщение в электронной почте факультету Computer Science с полным списком патчей Университета Миннесоты, начиная с 2018 г., связанных с исследованиями по безопасности в ядре Linux. Авторы сообщения стремились исчерпать конфликтную ситуацию и восстановить доверие между обеими сторонами.

Университет Миннесоты ответил 9 мая, признав предумышленно неисправными лишь четыре патча. Принося извинения за случившееся, представители УМ берут на себя обязательство соблюдать не только высокие академические, но и этические стандарты в своих исследованиях.



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru