LINUX.ORG.RU
Новости — Red Hat  

Для Fedora 17 утверждён план по переносу компонентов из корня в /usr и переход на Btrfs

 , ,


0

3

После обсуждения идеи переноса части компонентов корневой системы в /usr и объединения /sbin и /bin принято решение об утверждение планов по реализации первой идеи. Вторая идея одобрения не нашла. Обновленная структура корня будет выглядеть приблизительно следующим образом:

  • /usr - установленная система; общедоступно; возможность монтирования в режиме только чтения;
  • /etc - конфигурационные данные; локально;
  • /var - долговременные данные; локально;
  • /run - переменные данные; локально; обязательно использование tmpfs; 
 /
 |-- etc
 |-- usr
 |   |-- bin
 |   |-- sbin
 |   |-- lib
 |   `-- lib64
 |-- run
 |-- var
 |-- bin -> usr/bin
 |-- sbin -> usr/sbin
 |-- lib -> usr/lib
 `-- lib64 -> usr/lib64

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

Так же принято решение об очередной попытке перехода на Btrfs в качестве основной ФС. По сравнению с прошлым планом дополнительно заявлено о решении использовать стандартные для Btrfs механизмы управления томами, вместо LVM, и организации RAID.

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

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

О переходе на Btrfs

>>> О переносе компонентов из корня в /usr

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: daemonpnz (всего исправлений: 2)
← Открыта регистрация на второй семинар по системному администрированию в GNU|Linux
Opera 11.60 Tunny →
  1 2 3 4 5 6 7 8 9 10 11
Ответ на: комментарий от KennyMinigun

мне не комильфо пейсать скрипты. мне раньше больше нравилось.

shapovalov
()

Вот уже более 10-ти лет использую Linux на серверах и иногда на десктопах. Во всех этих установка у меня раздельные / и /usr, как говорится в лучших старых традициях. Однако последние несколько лет поддерживать такое разделение все сложнее и сложнее, раньше когда был минималистский initrd (только необходимое для загрузки root), минимальный root (только необходимое для начальной инициализации и монтирования остальных fs) все нормально работало, теперь в initrd запихали udev, хомячки захотели root на lvm и md и initrd превратился в свалку апофеозом которой стало появление опции modules=most и как следствие внос всего треша для поддержки всех этих most modules в initrd. Вы не находите, что поздно пить боржоми, когда почки отвалились? Раньше надо было возмущаться, но хомячки только радовались ведь они могли наконец загрузится с любимого зашифрованного раздела, теперь же, когда initrd фактически стал полноценной заменой старого root раздела, остается только смирится с этими изменениями и допилить его до полнофункциональной замены. Я уже не говорю о том, что первоначальная идея минималистского разделения никогда не работала в общем случае, а требовала непрерывного вноса приложений и библиотек для поддержки разнообразных вариантов загрузки то в root, то в initrd.

dik ★
()

<troll>ажите, а где мне теперь найти mount и dd и бизибокс, если я _случайно_ отмонтировал/угробил (нужное подчеркнуть) раздел, на котором у меня usr, а флешка с загрузочной системой осталась на работе?</troll>

ssvda ★
()

Ах ну да, Btrfs нуждается в интенсивном тестировании, так как разработка уже затянулась ни на шутку. Вот по этому и будут тестировать на федорофилах. Когда оттестят, начнут юзать в RHEL.

iron ★★★★★
()

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

Меня такая картина повергает в уныние и размышления об уходе на *BSD/Solaris/OSX.

Lonli-Lokli ★★
()
Ответ на: комментарий от Waterlaz

отвёртка себя изжила. пинцет - путь в будущее

так победим!

Lonli-Lokli ★★
()
Ответ на: комментарий от dik

Я и говорю, initrd - это старый добрый /, только сложнее в поддержки => нафиг нужен.

r2d2
()
Ответ на: комментарий от Waterlaz

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

dik ★
()
Ответ на: комментарий от Lonli-Lokli

Кстати, с установкой системы на btrfs разделение на / и /usr полностью теряет свой смысл, поскольку по сути это одна и та же фс. Сопли про прогресс это для хомячков, а в реальности им надоело соображать куда запихнуть ту или иную библиотеку или бинарник, проще все запихнуть в одно место ибо по сути, когда initrd все может само смысла монтировать сначала root, а потом /usr не осталось никакого.

dik ★
()
Ответ на: комментарий от shell-script

fixes (either security or only bug) have to be applied to only one place: the new DSO(s). If various applications are linked statically, all of them would have to be relinked. By the time the problem is discovered the sysadmin usually forgot which apps are built with the problematic library. I consider this alone (together with the next one) to be the killer arguments.

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

Security measures like load address randomization cannot be used.

Усложняет возможность пользование дырами в софте(саму дыру не правит, понятное дело), потенциально добавляя новые уязвимости(реальные уязвимости).

more efficient use of physical memory. All processes share the same physical pages for the code in the DSOs. With prelinking startup times for dynamically linked code is as good as that of statically linked code.

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

LD_PRELOAD - тоже потенциальные проблемы с безопасностью

all kinds of features in the libc (locale (through iconv), NSS, IDN, ...) require dynamic linking to load the appropriate external code.

Да, в glibc фактически поломали статическую линковку. Про то что в gnu много говна никто не сомневался. в bsd libc и uclibc таких проблем нет

no accidental violation of the (L)GPL. Should a program which is statically linked be given to a third party, it is necessary to provide the possibility to regenerate the program code

не технический аргумент.

tools and hacks like ltrace, LD_PRELOAD, LD_PROFILE, LD_AUDIT don't work.

и слава Богу, что костыли не только не работают, но и не нужны.

There are certainly more reasons. The often used argument about statically linked apps being more portable (i.e., can be copied to other systems and simply used since there are no dependencies) is not true since every non-trivial program needs dynamic linking at least for one of the reasons mentioned above.

это просто глупость. Почему это «needs»?

Waterlaz ★★★★★
()
Ответ на: комментарий от dik

Ну да, безопасность и экономия памяти - смешно,

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

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

Есть bsd libc и uClibc

Waterlaz ★★★★★
()
Ответ на: комментарий от zloy_buratino

Например гном 2, огнелис, ядро, офис... Да в линуксе навалом софта и библиотек для оптимизации.

И ты считаешь, что это должны делать люди из Fedora? А почему ты так считаешь?

Alsvartr ★★★★★
()
Ответ на: комментарий от Waterlaz

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

И Вы не догадываетесь почему?

myhand ★
()
Ответ на: комментарий от myhand

там уже исправили последнюю дырку?

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

Динамическая линковка - плохой метод повышения безопасности.

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

Как я начинаю представлять, что каждая программа содержит влинкованную функцию printf, мне становится не очень, а когда я вспоминаю про qt, gtk мне становится смешно, да говорят OpenGL ты статически не слинкуешь (разве только софтовую эмуляцию), а таких библиотек не мало.

BSD libc нет на Linux, а у uClibc весьма ограниченная функциональность.

http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt

dik ★
()
Ответ на: комментарий от Quasar

Quasar> Офигеть. Изменять чуть ли не важнейшую часть системы только потому, что мудило Поттеринг не смог осилить написать systemd нормально. Уьивать!
Выше мне написали, что я не прав, и системд таки нормально переваривает разделные / и /usr, а меня ввели в заблуждение лораналитики из предыдущего треда...

aleax
()
Ответ на: комментарий от alex-w

Это не повод устраивать помойку

помойку?

Каталогизация и структуризация - хорошая идея, если за структурой есть логика.

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

Как-то так интуитивно понятно, что login должен быть в /bin, а doom3 в /usr/bin, но вот для остального...

Waterlaz ★★★★★
()

/run - переменные данные; локально; обязательно использование tmpfs;
обязательно использование tmpfs
обязательно

Ну вы поняли, куда идут машины с RAM < 2Гб.

AlexCones ★★★
()
Ответ на: комментарий от Waterlaz

Уязвимость, посредством бага в libc. Точка.

Динамическая линковка - плохой метод повышения безопасности.

Некоторым танцорам еще и не такие вещи мешают...

myhand ★
()
Ответ на: комментарий от Waterlaz

если слинковать все статически, сильно ничего не изменится.

Если каждый апач будет тянуть с собой копию libc? Ага. Сильно - ничего, просто придется побольше плашек в сервер вставлять, дабы дц отапливать.

myhand ★
()
Ответ на: комментарий от F457

А любая дырка в C коде - проблема языка, а не кривых рук какого-то очередного быдлокодера.

myhand ★
()

Чего-то их Поттеринг не дожал, чтобы sbin упразднили. Опять лажа.

d_a ★★★★★
()
Ответ на: комментарий от myhand

Если каждый апач будет тянуть с собой копию libc? Ага. Сильно - ничего, просто придется побольше плашек в сервер вставлять, дабы дц отапливать.

Ты элементарно не владеешь вопросом. Они будут делить общие страницы памяти.

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

Динамическая линковка - плохой метод повышения безопасности.

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

AS ★★★★★
()
Ответ на: комментарий от myhand

Уязвимость, посредством бага в libc. Точка.

Динамическая линковка - плохой метод повышения безопасности.

Некоторым танцорам еще и не такие вещи мешают...

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

Waterlaz ★★★★★
()
Ответ на: комментарий от AS

Динамическая линковка - плохой метод повышения безопасности.

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

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

Waterlaz ★★★★★
()
Ответ на: комментарий от LMD

да смотрел я на списки рассылки федоры, их там тысячи, в какой именно писать такую хрень? Или в какой форум? и в какой канал?

gaga ★
()
Ответ на: комментарий от alx_me

использующие для квотирования «<<-----Цитата----<<».

Это ужасно. Причем и для чтения, и вообще как явление в 2011 году.

Jayrome ★★★★★
()
Ответ на: комментарий от Waterlaz

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

Да, я буду уверен. что исправил проблему.

Какими затратами ?

При динамической линковке и версиях символов я вообще не в чем не могу быть уверен.

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

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8 9 10 11
← Открыта регистрация на второй семинар по системному администрированию в GNU|Linux
Red Hat
Opera 11.60 Tunny →