Страницы

2014-03-29

Файловая система Tux3 вероятно будет добавлена в ядро Linux

Разработчик Дэниел Филипс, работающий в компании Samsung, сообщил в неформальной беседе во время Linux Foundation Collaboration Summit, что его файловая система Tux3 возможно скоро будет включена в основное ядро Linux. По заявлению разработчика, компания Samsung заинтересована в использовании данной файловой системы во встраиваемых системах даже больше чем в недавно включённая в состав ядра ФС F2FS, также разработанной сотрудниками Samsung. Отмечается, что разработчик Tux3 взаимодействует в том числе и с командой разработчиков F2FS.

Файловая система Tux3 разрабатывается с 2008 года и является версионной файловой системой. В 2009 году работа над Tux3 была приостановлена, но в начале 2013 года проект возродился и начал интенсивно развиваться. Для хранения большинства структур используются b-tree и предложенные автором Tux3 версионированные указатели. Файловая система обеспечивает атомарные транзакции и запись в произвольные области ("write-anywhere").

Особый интерес представляют заявления разработчиков о скорости работы данной файловой системы. Например, Tux3 известен тем, что в одном из тестов смог обогнать tmpfs, что ранее считалось невозможным, так как tmpfs является довольно тонкой прослойкой между VFS и SWAP. Дополнительно разработчик отмечает, что имеются планы по поддержке сжатия на лету и снапшотов.

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

Значительный выпуск серверной Linux-системы CoreOS

Представлено значительное обновление проекта CoreOS, в рамках которого развивается не похожее на традиционные Linux-дистрибутивы серверное окружение, напоминающее по сути ChromeOS, но нацеленное на массовое развёртывание серверных систем. Отмечается, что опубликованная сборка является первым релизом на пути к полной стабилизации кодовой базы и обеспечения готовности для промышленного использования. Готовые базовые образы CoreOS подготовлены для запуска c использованием PXE-загрузки, Amazon EC2, Google Compute Engine, OpenStack, VirtualBox, VMware, Vagrant и QEMU/KVM. Наработки проекта распространяются под лицензией Apache 2.0.
Система содержит только минимальный набор компонентов, достаточный для выполнения изолированных контейнеров (cgroups+namespaces), которые в свою очередь содержат произвольную начинку для запуска необходимых серверных приложений. По сути, в состав базовой системы входит только ядро Linux, системный менеджер systemd и ряд служебных сервисов для управления конфигурацией и установки обновлений. Системный раздел монтируется в режиме только для чтения и не изменяется в процессе работы.
Для установки обновлений используется подход ChromeOS, при котором одновременно создаётся два дисковых раздела. Один из разделов является активным, а второй используется для копирования обновления, после установки которого активным становится второй раздел, а первый остаётся для установки следующего обновления и предоставляет возможность быстрого отката изменений. Таким образом, при каждом обновлении разделы меняются местами. Обновления могут устанавливаться автоматически, по аналогии с ChromeOS. По задумке разработчиков, обновление серверов на базе CoreOS должно производиться также просто, как в настоящее время осуществляется обновление браузеров.
Вместо традиционных пакетных менеджеров предлагается использовать преднастроенные изолированные контейнеры, содержащие все необходимые компоненты для выполнения того или иного серверного приложения. Упаковка приложений в произвольные обособленные контейнеры позволяет не задумываться об особенностях базовой ОС и свободно переносить контейнеры от одной ОС к другой и с сервера на сервер. В качестве системы управления контейнерами поддерживается Docker, предоставляющий средства для автоматизации создания изолированных окружений для запуска произвольных процессов и возможности по переносу и клонированию окружений на другие серверы. При этом Docker не является обязательным, присутствует возможность создания контейнеров вручную или использования уже готовых образов, пригодных для использования с инструментарием LXC.
Другой особенностью CoreOS являются средства автоматического определения доступных сервисов, использования единой конфигурации для группы серверов и объединения набора серверов во взаимосвязанные кластерные системы. Для обмена и управления конфигурацией используется система etcd, развиваемая специально для CoreOS. Код etcd написан на языке Go и поставляется под лицензией Apache. Etcd представляет собой высоконадёжное хранилище параметров конфигурации в форме ключ/значение. Для доступа к конфигурации предоставляется простой интерфейс, основанный на использовании HTTP и JSON (запросы могу отправляться при помощи утилиты curl или специальной утилиты etcdctl). Аутентификация выполняется на основе SSL-ключей. Хранилище конфигурации и логи реплицируются на все узлы и поддерживается в синхронизированном состоянии с использованием протокола Raft.
Новый выпуск примечателен переходом к новой раскладке файловой системы, в которой раздел /etc допускает запись, а /usr примонтирован отдельно в режиме только для чтения. Если ранее весь корень монтировался в режиме только для чтения, то теперь отдельно монтируется раздел /etc, а вся специфичная для системы функциональность, подлежащая обновлению вынесена в раздел /usr, который монтируется отдельно и используется для цикличного обновления системы. Реализация Docker обновлена до выпуска 0.9, в том числе с возможностью использования файловой системы Btrfs. В частности, Btrfs теперь используется для корневой ФС и статических разделов. Для настройки сетевых параметров задействована новая подсистема systemd-networkd.
На этапе инициализации задействована система CloudInit, позволяющая задавать конфигурацию окружения на этапе загрузки в отдельном файле cloud-config.yml. В том числе, через заданные в cloud-config.yml параметры можно создавать пользователей, добавлять ssh-ключи, записывать юниты systemd и контролировать их запуск, создавать произвольные файлы в ФС, передавать параметры сети. Таким образом общий загрузочный образ может быть унифицирован и не привязан к конкретным конфигурациям.

2014-03-21

Прекращение поддержки Windows XP способствует переводу банкоматов на Linux

По данным директора Ассоциации производителей банкоматов некоторые крупные финансовые компании США намерены перевести свои сети банкоматов на Linux для получения более полного контроля над циклами обновления программного обеспечения и оборудования. Основным стимулом перевода на Linux является прекращение поддержки Windows XP, начиная с 8 апреля нынешнего года, несмотря на продолжение активного использование данной ОС на предприятиях.
Для банкоматов ситуация становится критической, с учётом того, что 95% банкоматов до сих пор продолжают работать под управлением Windows XP. Миграция на Windows 7 не является выходом, так как данная ОС требует более мощного оборудования, а время жизни банкомата варьируется от 7 до 15 лет.
Бессилие что-либо изменить вынуждает компании искать альтернативные решения, избавленные от привязки к вендору и не зависящие от расписания выпуска обновлений Microsoft. Использование Linux даёт возможность синхронизировать жизненный цикл оборудования и используемого на нём программного обеспечения, а также позволяет обеспечить выпуск исправлений собственными силами, в случае неадекватных решений вендора.

source1
source2

Представлен XenGT, механизм виртуализации GPU от компании Intel


Разработчики гипервизора Xen представили развиваемый компанией Intel проект XenGT, нацеленный на создание решения для полной виртуализации GPU и обеспечения работы прослойки для взаимодействия из гостевых систем с реальными GPU Intel. XenGT подразумевает поддержание отдельных виртуальных GPU для каждого виртуального окружения, за которыми закрепляется часть критичных для обеспечения высокой производительности ресурсов реального GPU.
Возможность использования обычных нативных видеодрайверов внутри виртуальных окружений без вмешательства гипервизора в областях, важных для достижения высокой производительности, обеспечивает оптимальное соотношение между функциональностью, производительностью и совместным использованием ресурсов. Таким образом XenGT приближает производительность графической подсистемы к конфигурациям с полным пробросом доступа к GPU, предоставляя при этом возможность совместного использования GPU между виртуальными машинами, без применения полной эмуляции или трансляции API DirectX/OpenGL. Несмотря на то, что в настоящее время в XenGT поддерживается только Xen и графическая подсистема процессоров Intel, отмечается что базовая логика является универсальной и может легко быть портирована для других систем виртуализации.
Для организации работы виртуальных GPU на стороне хост-системы (dom0) запускается специальный драйвер vgt, который берёт на себя функции планировщика, координирующего совместный доступ и распределение ресурсов реального GPU между виртуальными машинами. Ресурсы GPU логически разделяются на две категории: критичные для обеспечения высокой производительности (работа с видеопамятью и буферами команд в памяти) и все остальные (MMIO/PIO, регистры конфигурации PCI, таблицы GTT и пополнение очереди команд GPU). Для первой категории обеспечивается прямой проброс к реальному GPU, для второй выполняется диспетчеризация через промежуточную прослойку, на стороне которой выполняется разделение доступа и эмуляция виртуальных GPU.


source1
source2

2014-03-14

Apache удалён из базовой системы OpenBSD


Разработчики OpenBSD удалили http-сервер апач из состава базовой системы. Всем пользователям, использующим /usr/sbin/httpd из состава OpenBSD, следует обратить особое внимание при проведении обновления после публикации следующего релиза, в частности, перед обновлением нужно скопировать контент пользователя из таких директорий, как /var/www/conf/, /var/www/cgi-bin/ и /var/www/htdocs/.

Вместо Apache рекомендуется использовать nginx, который интегрирован в базовую систему начиная с выпуска OpenBSD 5.2, или воспользоваться портом www/apache-httpd-openbsd. Напомним, что разработчиками OpenBSD поддерживалось собственное ответвление от Apache 1.3.29, дополненное большим числом патчей для усиления безопасности и поддержкой таких возможностей как SSL/TLS и DSO.

source1
source2

2014-03-13

OpenBSD перешёл на использование OpenSMTPD по умолчанию

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

Почтовый сервер OpenSMTPD с 2008 года развивается под эгидой проекта OpenBSD и нацелен на создание простой и безопасной замены Sendmail. Сервер поддерживает большую часть требований RFC 5321 и реализует ряд используемых повсеместно расширений протокола, в том числе предоставляет поддержку аутентификацию пользователей (SMTP AUTH), SSL/TLS шифрование трафика, механизма уведомления о доставке DSN (Delivery Status Notification), расширенных кодов статуса (Enhanced Status Codes), системы блокирования спама по "серым спискам" (через интеграцию со spamd), бэкендов для хранения таблиц в Redis, SQLite, LDAP, PostgreSQL и SOCKETMAP. Для пользователей систем, отличных от OpenBSD, развивается переносимая версия OpenSMTPD.

source1
source2

2014-03-11

Новая версия системы управления контейнерной виртуализацией Docker 0.9

Увидел свет выпуск инструментария для управления изолированными Linux-контейнерами Docker 0.9. Docker предоставляет высокоуровневый API, позволяющий манипулировать контейнерами на уровне изоляции отдельных процессов. В частности, Docker позволяет не заботясь о формировании начинки контейнера запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров.

Код Docker написан на языке Go и распространяется под лицензией Apache 2.0. Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров могут использоваться libcontainer, lxc, libvirt, systemd-nspawn и т.п. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить "docker run -i -t base /bin/bash").

При подготовке новой версии основное внимание уделялось не расширению функциональности, а повышению стабильности и увеличению качества. В связи с этим новый выпуск примечателен добавлением только двух значительных новшеств:
  • Новый драйвер по умолчанию - libcontainer, который предоставляет интерфейс для прямого обращения к средствам ядра Linux, обеспечивающим работу изолированных контейнеров (cgroups, пространства имён, Apparmor, SELinux, netlink, capabilities и т.д.). Libcontainer позволяет обойтись без ранее используемых прослоек и зависимостей, таких как lxc, libvirt или systemd-nspawn. Поддержка LXC теперь является опциональной. Libcontainer написан на языке Go и оформлен в виде самодостаточной библиотеки, не привязанной к Docker, что позволяет использовать её и в сторонних проектах для манипуляции такими сущностями, как cgroups и пространства имён;
  • Универсальный API драйверов обеспечения запуска (execution driver API), который можно использовать для настройки исполняемой среды, окружающей каждый контейнер. Указанный API позволяет задействовать различные инструменты для обеспечения изоляции, каждый из которых обладает своими особенностями и установочной базой: OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones и chroot. Поддержка LXC по-прежнему реализуется в отдельном драйвере.
Особенности выпуска Docker 0.9:
Основные возможности Docker:
  • Возможность размещения в изолированном окружении разнородной начинки, включающей различие комбинации исполняемых файлов, библиотек, файлов конфигурации, скриптов, файлов jar, gem, tar и т.д.
  • Поддержка работы на любом компьютере на базе архитектуры x86_64 с системой на базе современного ядра Linux, начиная от ноутбуков, заканчивая серверами и виртуальными машинами. Возможность работы поверх немодифицированных современных ядер Linux (без наложения патчей) и в штатных окружениях всех крупных дистрибутивов Linux, включая Fedora, RHEL, Ubuntu, Debian, SUSE, Gentoo и Arch;
  • Использование легковесных контейнеров для изоляции процессов от других процессов и основной системы.
  • Так как контейнеры используют свою собственную самодостаточную файловую систему, не важно где, когда и в каком окружении они запускаются.
  • Изоляция на уровне файловой системы: каждый процесс выполняется в полностью отдельной корневой ФС;
  • Изоляция ресурсов: потребление системных ресурсов, таких как расход памяти и нагрузка на CPU, могут ограничиваться отдельно для каждого контейнера с использованием cgroups;
  • Изоляция на уровне сети: каждый изолированный процесс имеет доступ только к связанному с контейнером сетевому пространству имён, включая виртуальный сетевой интерфейс и привязанный к нему IP-адрес;
  • Корневая файловая система для контейнеров создаётся с использованием механизма copy-on-write (отдельно сохраняются только изменённые и новые данные), что позволяет ускорить развёртывание, снижает расход памяти и экономит дисковое пространство;
  • Все стандартные потоки (stdout/stderr) каждого выполняемого в контейнере процесса накапливаются и сохраняются в виде лога;
  • Изменённая файловая система одного контейнера может использоваться в качестве основы для формирования новых базовых образов и создания других контейнеров, без необходимости оформления шаблонов или ручной настройки состава образов;
  • Возможность использования интерактивной командной оболочки: к стандартному вводу любого контейнера может быть привязан псевдо-tty для запуска shell.
  • Поддержка использования разных систем хранения, которые могут подключаться как плагины. Среди поддерживаемых драйверов хранения заявлены aufs, device mapper (используются снапшоты LVM), vfs (на основе копирования директорий) и Btrfs. Ожидается появление драйверов для ZFS, Gluster и Ceph;
  • Возможность создания контейнеров, содержащих сложные программные стеки, через связывание между собой уже существующих контейнеров, содержащих составные части формируемого стека. Связывание осуществляется не через слияние содержимого, а через обеспечения взаимодействия между контейнерами (создаётся сетевой туннель). 

source1
source2

Релиз системы виртуализации Xen 4.4.0

После восьми месяцев разработки представлен релиз свободного гипервизора Xen 4.4. По сравнению с прошлым выпуском в Xen 4.4 внесено 1193 изменений, в том числе добавлена поддержка нового режима PVH, произведена интеграция libvirt с libxl, улучшена поддержка SPICE, обеспечена поддержка вложенного запуска окружений, подготовлена возможность запуска гостевых систем в режиме EFI, улучшена поддержка архитектуры ARM.
В процессе подготовки Xen 4.4 разработчики попытались перейти на 6-месячный цикл формирования выпусков, но из-за праздников и непредвиденных проблем разработка затянулась на 6 дополнительных недель. При разработке Xen 4.4 также была значительно увеличена интенсивность тестирования кодовой базы: в систему регрессивного тестирования osstest добавлены дополнительные тесты, код Xen прошёл проверку в тестовом наборе XenRT компании Citrix, были учтены результаты статического анализа кода в системе Coverity. В связи с этим, разработчики позиционируют Xen 4.4 как один из самых безопасных и надёжных выпусков.
Ключевые улучшения в Xen 4.4:
  • Экспериментальная поддержка режима PVH для гостевых систем, который комбинирует элементы режимов паравиртуализации (PV) и полной виртуализации (HVM). В режиме PVH с одной стороны применяется полная виртуализация на уровне ограничения привилегированных инструкций, изоляции системных вызовов и виртуализации таблиц страниц памяти, но с другой стороны используются методы паравиртуализации для ввода/вывода, обработки прерываний, организации загрузки и взаимодействия с оборудованием. Таким образом, PVH, как и режим PV, обеспечивает высокую производительность, благодаря исключению накладных расходов на симуляцию аппаратных устройств, но использует вместо PV MMU свойственные HVM механизмы аппаратной виртуализации для обеспечения более строгой изоляции виртуальных окружений. Поддержка работы в качестве гостевой системы PVH уже присутствует во FreeBSD 10 и Linux.
  • Для библиотеки libvirt, предоставляющей средства для унифицированного локального и удаленного управления виртуальными окружениями, выполнена работа по обеспечению поддержки библиотеки libxl с реализацией API для использования в сторонних приложениях возможностей нового инструментария XL, пришедшего на смену XM/XEND. В результате обеспечена возможность интеграции XL с любыми инструментами, которые поддерживают libvirt, от графических менеджеров виртуальных машин до облачных платформ, подобных CloudStack и OpenStack;
  • Новый масштабируемый интерфейс для каналов событий (паравиртуализированных прерываний), в котором устранены ранее действующие ограничения в 1024 и 4096 каналов на домен для 32- и 64-разрядных систем. С учётом того, что Dom 0 использует несколько каналов событий для каждой гостевой системы (обычно 4), на одном сервере получалось запустить не более 300-500 гостевых систем. В условиях использования мощных многоядерных систем или запуска в гостевых окружениях легковесных операционных систем, таких как Mirage и OSv, нацеленных на выполнение обособленных программ поверх гипервизора, указанные ограничения становятся узким местом в инфраструктуре. Новый ABI на основе FIFO поднимает лимит до более 100 тысяч каналов событий, а также предоставляет поддержку установки множественных и справедливых приоритетов. Новый API требует специальной поддержки со стороны гостевой системы, например, подобная поддержка появится в ядре Linux 3.14.
  • Поддержка виртуализации на системах с архитектурой ARM получила статус стабильной. ABI гипервизора для ARM и ARM64 стабилизирован и отныне будет развиваться с учётом сохранения обратной совместимости, что позволит без изменения использовать в будущих выпусках Xen гостевые системы, использующие Xen 4.4 ARM ABI. В порт для ARM добавлена порция новых функций: обеспечена возможность хранения образов гостевых систем на дисковых разделах или разделах LVM при помощи xen-blkback, в 64-разрядный порт Xen для ARM добавлена поддержка загрузки гостевых систем, реализована поддержка протокола ARM/multiboot, добавлена поддержка PSCI, добавлена поддержка плат Arndale, Calxeda ECX-2000 (Midway), Applied Micro X-Gene Storm, TI OMAP5 и Allwinner A20/A30;
  • Поддержка создания вложенных виртуальных окружений на оборудовании Intel. Гостевые системы HVM могут получить доступ к возможностям виртуализации оборудования, позволяющим запустить в гостевой системе собственный гипервизор, например, Xen, KVM, VMWare или HyperV. Вложенная виртуализация пока не готова для промышленного применения, но уже достаточно зрела для перехода из категории экспериментальных возможностей на стадию пригодности для начального ознакомления (tech preview);
  • В основную кодовую базу GRUB интегрирован код для поддержки протокола Xen pv, что позволит добиться полной совместимости с Xen в будущих выпусках GRUB и избавиться от необходимости использования отдельного порта pvgrub для образов гостевых систем, работающих в режиме паравиртуализации;
  • В реализацию протокола SPICE, используемого для организации доступа к виртуализированным рабочим столам, добавлена поддержка перенаправления USB, совместного доступа к буферу обмена и возможность использования vdagent;
  • Улучшена интеграция Xen с распределенной файловой системой GlusterFS. В GlusterFS 3.5 появилась поддержка создания iSCSI-узлов, что позволяет создать iSCSI устройства в Dom0 и обеспечить хранение дисков гостевых систем в GlusterFS;
  • Домены драйверов в Linux избавлены от привязки к событиям udev, используемым для запуска бэкендов для гостевых систем. Вместо udev теперь используется собственный демон, работающий поверх libxl и обеспечивающий более высокий уровень гибкости при запуске бэкендов в форме пользовательских процессов, например, теперь можно запускать бэкенды Qdisk, что было невозможно с udev;
  • Экспериментальная поддержка загрузки гостевых систем в режиме EFI;
  • Улучшена поддержка использования в окружении Xen облачной операционной системы Mirage OS, которая обеспечивает возможность запуска поверх гипервизора приложений на языке OCaml с минимальной системной обвязкой;
  • Компоненты QEMU обновлены до версии 1.6, SeaBIOS обновлён до версии 1.7.3.1;
Дополнительно можно отметить выпуск Xen Orchestra 3.3, web-интерфейса для администрирования системы виртуализации на базе XCP (Xen Cloud Platform), XenServer и других систем, поддерживающих протокол xapi. Проект позиционируется как многоплатформенная и свободная альтернатива проприетарному продукту XenCenter. Xen Orchestra предоставляет web-интерфейс для выполнения ежедневных типовых задач администраторов систем на базе гипервизора Xen, таких как управление виртуальными машинами и серверами XCP, в том числе миграция окружений между пулами, управление репозиториями хранения и визуализация состояния инфраструктуры виртуализации. В новой версии добавлена поддержка создания снапшотов, удаления хоста из пула, инициирования действий с хостом (перезапуск стека, перезагрузка, завершение работы), управления содержимым лога.


source1
source2

2014-03-09

Разработчики systemd представили механизм автоматического монтирования разделов на основе GPT-меток

В списке рассылки разработчиков systemd представлена реализация автоматического обнаружения и монтирования разделов, основанная на идентификаторах типов разделов, используемых в разметке GUID Partition Table (GPT). Такой подход в перспективе позволяет отказаться от использования файла /etc/fstab в некоторых ситуациях.
Формат разметки диска GPT является современной альтернативой классическому методу разметки, основанному на сохранении таблицы разделов в главной загрузочной записи (MBR). Существенным преимуществом формата GPT является поддержка жестких дисков объемом до 9.4 зетабайт, в то время как MBR-разметка ограничивается 2.2 терабайтами. Кроме того, формат GPT, в отличие от MBR, полностью совместим с EFI-системами.
Предложенный разработчиками systemd механизм основан на 16-байтовых идентификаторах типов разделов, используемых в таблице разделов формата GPT. Например, раздел подкачки идентифицируется как 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F. В отличие от уникальных идентификаторов разделов (UUID), идентификаторы типов известны заранее. Это позволяет автоматически обнаруживать и монтировать разделы, основываясь на их типе. В частности, в настоящий момент systemd поддерживает автоматическое обнаружение корневого раздела, /boot (загрузочный EFI-раздел), /home, /srv и разделов подкачки.
Эта функция реализована при помощи двух специальных модулей, systemd-auto-gpt-generator и systemd-efi-boot-generator. На ранних этапах загрузки они анализируют таблицы разделов всех доступных дисков и создают соответствующие юниты, описывающие точки монтирования и устройства подкачки. Механизм обнаружения раздела автоматически отключается, если монтирование в данную точку было уже настроено вручную (через /etc/fstab или юнит-файл), а также в том случае, если каталог, в который производится монтирование, не пуст. Если в системе имеется несколько разделов одного типа, используется первый из найденных (за исключением разделов подкачки, количество которых не ограничивается).
Такой подход упрощает установку и администрирование систем в некоторых ситуациях, в частности, при наличии нескольких установленных Linux-систем, использующих общие разделы с информацией пользователей (/home) и системных демонов (/srv), а также разделы подкачки. Кроме того, значительно упрощается работа с live-системами и образами виртуальных контейнеров, которые теперь могут подключать разделы без дополнительной настройки. В простейших случаях, например, при наличии одного корневого раздела и одного раздела /home, становится возможным полностью отказаться от использования файла /etc/fstab.
В более сложных ситуациях, требующих дополнительных настроек, рекомендуется, как и раньше, использовать /etc/fstab или юнит-файлы. Автоматическое обнаружение некоторых других типов разделов, в частности, /var и /usr, поддерживать не планируется, так как содержимое этих разделов сильно обусловлено спецификой дистрибутивов, и их совместное использование несколькими установленными дистрибутивами Linux весьма проблематично.

source1
source2

2014-03-06

Рассматривается возможность обеспечения длительной LTS-поддержки Debian Squeeze

Участники команды Debian Security Team подвели итоги состоявшейся в феврале встречи разработчиков. Среди прочего, сообщается о возможности реализации расширенной поддержки (LTS) для прошлой стабильной ветки Debian Squeeze. В соответствии с устоявшейся практикой, поддержка прошлой стабильной ветки прекращается спустя год после выпуска очередного значительного релиза. Время поддержки Debian Squeeze истекает в мае. В случае воплощения плана по приданию Debian Squeeze статуса LTS, обновления с устранением уязвимостей будут выпускаться значительно дольше.

Обновления планируется поставлять через отдельный репозиторий squeeze-lts. Выпуск обновлений будет ограничен для архитектур amd64 и i386. Кроме того, на некоторые пакеты, в силу их специфики, не будет распространяться расширенная поддержка. С другой стороны, планируется ограничить время поддержки для некоторых видов пакетов из состава Wheezy, таких как браузеры на базе движка WebKit.

Из планов, в отношении будущих выпусков, отмечается переход на улучшенную систему защиты по переполнения стека, которая появится в GCC 4.9 (-fstack-protector-strong). В настоящее время для около 95% стандартных или приоритетных пакетов (priority:standard или выше) обеспечена возможность сборки с включением дополнительной защиты через dpkg-buildflags (дополнительные проверки формирования строки, D_FORTIFY_SOURCE, защита стека и т.д.). Рассматривается возможность включения по умолчанию опции монтирования hidepid=1 для procfs, при которой пользователю запрещён вход в поддиректории /proc/pid/ с данными о непринадлежащих ему процессах, что позволит защититься от целого класса проблем, связанных с утечкой информации.

Также планируется пересмотреть подготовку исправлений для уязвимостей, связанных с атаками через символические ссылки. В поставляемом в Wheezy ядре включена опция блокирования подобных атак (fs.protected_symlinks), что позволяет рассматривать некоторые категории связанных с символическими ссылками уязвимостей как неопасные для пользователей дистрибутива. С другой стороны, подобная функция не включена для сборок на базе ядер FreeBSD и Hurd, поэтому будут рассмотрены способы реализации аналогичной защиты для данных платформ.

source1
source2

2014-03-03

Леннарт Поттеринг (Lennart Poettering) объявил о создании репозитория systemd-stable, в котором будет осуществляться поддержка стабильных веток systemd. По мере развития новых выпусков systemd, наиболее важные исправления будут бэкпортироваться для прошлых выпусков, отнесённых в категории стабильных. Создание стабильных веток нацелено на избавление от дублирования одной и той же работы в процессе поддержания пакетов systemd в разных дистрибутивах. В настоящее время стабильная поддержка предоставляется для выпусков 208 и 210.

source1
source2