Russian Fedora - сообщество русскоязычных участников международного проекта Fedora

Гентушник и дистрохоппер Greg Kroah-Hartman представил первый вариант патчсета для kdbus. Если все будет хорошо, то можно будет успеть к версии 3.19. В целом довольно быстро получилось - понадобилось чуть менее пары лет, чтоб представить первый патчсет.

Наш коллега Joey Hess из Debian открыл новый кейс использования systemd.
Я научил свой ноутбук просыпаться в 7:30 утра. Когда он просыпается - он запускает всё, что написано в моём

~/bin/goodmorning

скрипте. После чего, если крышка ноутбука продолжает быть закрыта - он переключается обратно в спящий режим.
Это программируемый будильник, для работы которого не требуется чтобы ноутбук был включен всю ночь.
Но, он необязательно играет музыку и будит меня (я редко хочу просыпаться от будильника, просыпаться когда солнце светит в окно гораздо приятнее). Он может обрабатывать другие задачи, как загружать почту, прежде чем я проснусь. У меня дома стоит dial-up и процесс загрузки почты занимает час утром, так что было бы неплохо, чтобы почта загрузилась пока я сплю.
Это заняло некоторое время, чтобы выяснить как оно работает, но это оказалось удивительно просто. Кроме

~/bin/goodmorning

, что может быть любой программой/скриптом, мне нужно всего 2 файла, чтобы systemd запускал это.

/etc/systemd/system/goodmorning.timer

[Unit]
Description=good morning

[Timer]
Unit=goodmorning.service
OnCalendar=*-*-* 7:30
WakeSystem=true
Persistent=false

[Install]
WantedBy=multi-user.target

/etc/systemd/system/goodmorning.service

[Unit]
Description=good morning
RefuseManualStart=true
RefuseManualStop=true
ConditionACPower=true

[Service]
Type=oneshot
ExecStart=/bin/systemd-inhibit --what=handle-lid-switch --why=goodmorning /bin/su joey -c /home/joey/bin/goodmorning

Установка:

После установки вышеуказаных файлов, запустите (с привелегиями суперпользователя):

systemctl enable goodmorning.timer; systemctl start goodmorning.timer

После чего, вы так же должны отредактировать

/etc/systemd/logind.conf

установив в нём

LidSwitchIgnoreInhibited=no

-- это позволит systemd-inhibit блокировать уход в спящий режим при закрытии крышки ноутбука.

Всё слишком просто

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

WakeSystem=true

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

ConditionACPower=true

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

xfce workaround

При использовании xfce, xfce4-power-manager берёт управление системой при закрытии крышки на себя и сейчас запрещает системе возвращаться в сон если крышка ноутбука закрыта когда скрипт goodmorning завершается. К счастью, есть простой workaround; он настраивает xfce не переопределять поведение переключателя крышки.

xfconf-query -c xfce4-power-manager -n -p /xfce4-power-manager/logind-handle-lid-switch -t bool -s true

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

прочему не пользовательский юнит?

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

HP неспроста повысило свой уровень участия в OpenStack. Они, вслед за другими ведущими игроками облачных технологий, предложили свой вариант для развертывания облака - HP Helion OpenStack. Пока доступна лишь Community Edition, но вскоре можно ожидать и платный вариант. Мы уже рассказывали про HP Helion ранее, но теперь, после доходящих до нас слухов о том, что Debian Community негласно управляется из HP, становится понятно, почему Debian стремительно переходит на systemd невзирая на стоны любителей юниксвэя.

Бразильский мачо и инженер Red Hat, Lucas Meneghel Rodrigues, разрабатывавший систему тестирования виртуализированных систем Autotest (напомню, мы никогда не недооценивали важность тестирования), начал разработку нового поколения системы тестирования - Avocado. Ознакомьтесь со слайдами с презентации этого проекта. И, конечно, и autotest, и avocado уже доступны в Copr-репозитории на попробовать.

Вышло новое интервью с Julien Danjou, разработчиком Awesome и OpenStack.

Matthew Garrett прокомментировал доклад Jérôme Petazzoni о безопасности в контейнерах (внимание, Garrett ведет свой блог на частично запрещенном в РФ хостинге, так что используйте варианты обхода государственной цензуры в РФ, чтобы ознакомиться с его постами). Напомним, Dan Walsh тоже выступал с докладом о безопасности в контейнерах. Также напомним, что Jérôme Petazzoni выступает 29 октября в Москве на митапе про Docker и контейнерную виртуализацию.

Iron.io рассказывает о своем опыте запуска 300.000.000 Docker-контейнеров. Из результатов особо отметим, что они видят большой потенциал в связке CoreOS + Docker.

Brandon Phillips, основатель CoreOS, недавно выступал на LinuxCon Europe 2014 с докладом о etcd и fleet. Про etcd он уже рассказывал, и интересно посмотреть, чего с тех пор появилось нового.

И последняя печальная новость, не совсем про облака - представитель компании ownCloud потребовал от Canonical удалить устаревшую и глючную версию одноименного пакета из их репозитория. Мы всегда говорили, что меряться надо не размерами репозиториев, а какой-то иной метрикой, например количеством активных мэйнтейнеров или количеством изменений в единицу времени. Большое количество пакетов, и небольшое количество активных мэйнтейнеров, это означает лишь то, что значительную массу этих пакетов составляет глючное и устаревшее ПО, в т.ч. с дырами безопасности. У нас порядка тысячи-полутора мэйнтейнеров, сопровождающих около 10-15 тысяч пакетов, и это очень малое количество рабочих рук. Не вдаваясь в подробности скажем, что если один мэйнтейнер приходится на несколько сотен или даже тысяч пакетов, и утверждается, что качество пакетной базы дистрибутива высокое, то это заведомый (само)обман.

Наконец-то, после 25й (!) итерации, OverlayFS включили в дерево vfs.git. Еще пара-тройка шагов, и его включат в официальный Git-репозиторий Торвальдса.

OverlayFS, это результат более чем четырехлетней разработки Miklos Szeredi, разработчика FUSE. Целью проекта является создание "многослойной" файловой системы, объединяющей другие файловые системы в одну, и предоставляющей возможность "форка" полученной системы. Одним из приложений этой функциональности были LiveCD, которые таким образом планировали предоставлять возможность прозрачного доступа к системе на чтение-запись. Еще вариантом использования была функциональность "factory reset" в embedded-системах (телефоны, роутеры, медиаплейеры), когда основная система никогда не изменялась, а настройки велись в union-fs. С развитием облачных технологий появилось еще одно применение - большая часть облачных систем идентична, и хочется эту общую часть разделять между сотнями и тысячами контейнеров в хостовой системе одновременно позволяя всем контейнеризированным приложениям ее изменять, если нужно.

Существовало несколько реализаций Union-FS в разных системах (хороший обзор был сделан Valerie Aurora на LWN.net - первая часть и вторая часть), но в Linux ни одна из реализаций не добралась до ванильного ядра. Причин тому много - архитектурная усложненность, низкое качество кода, высокий уровень ненависти в рассылке ядра социально-личностные проблемы. Ближе всех к ядру подобралась было AuFS, и ее даже поспешно включили в ряд Debian-based дистрибутивов. Но быстро выяснилось, что это было ошибкой, т.к. система оказалась чрезвычайно сложной, хрупкой, и бесперспективной для включения в ядро. Но ущерб поспешными действиями мэйнтейнеров был нанесен - разработчики Docker, по наивности полагаясь на возможности, присутствовавшие в самом популярном Linux-дистрибутиве, решили базироваться на aufs. Непонятно, почему они не проконсультировались с нашими коллегами, которые бы наверняка подсказали более рациональное решение. Так или иначе, когда у Red Hat появился интерес к Docker, то наши коллеги протянули руку помощи зашедшему в архитектурный тупик проекту, переведя его на Device Mapper.

История OverlayFS началась давно, и по сравнению с другими вариантами, система выглядела очень простой. Мэйнтейнеры ядра, придерживаясь их неповторимого стиля общения в списке рассылки ядра, отозвались о патчсете окрыляюще для начинающих - Andrew Morton сказал, что ему проще не принимать его, а на последовавшее предложение перенести функционал в FUSE-модуль в userspace, Linus Torvalds, в присутствии разработчика userspace-файловых систем, высказался, что люди, разрабатывающие файловые системы в userspace просто заблуждаются. Получив свою дозу мотиваторов, Miklos за три года совершил еще две дюжины попыток, и наконец-то пробился!

Одним из первых пользователей OverlayFS были разработчики OpenWRT, и недаром - factory reset и откат при аварии обновления для них является обязательной фичей. Как вы знаете, атомарное, консистентное, изолированное и надежное обновление системы в рамках старой Linux-архитектуры сейчас в общем случае невозможно. Особенно сложно добиться хотя бы частичного удовлетворения ACID, если использовать не RPM, а один из нестандартных самодельных пакетных менеджеров (некоторые из них довольно популярны, и их примитивность и малофункциональность порой видится их наивными пользователями как преимущество перед сложным RPM). Наши коллеги работают над надежными апдейтами довольно давно - offline-апдейты, перенос всего в /usr, использование btrfs, контейнеризация и изоляция приложений, инициатива Fedora Atomic, и многое другое. До чего-то работающего еще пока, к сожалению, довольно далеко.