В Fedora рассматривают предложение перенести все исполняемые файлы в /usr/bin
7
Иллюстрация с сайта flickr.com
В проекте Linux-дистрибутива Fedora начали обсуждение предложения по «объединению» всех исполняемых файлов из каталогов /bin, /sbin, /usr/bin и /usr/sbin в одном месте — /usr/bin.
На самом деле, в недрах проекта Fedora зреет даже более масштабный план: отказ от корневых каталогов /bin, /lib, /lib64 и /sbin в пользу их перемещения в /usr (см. UsrMove в wiki проекта Fedora). Работа по унификации директории для исполняемых файлов является частью этого плана. В ее рамках предлагается и устранить различие между «bin» и «sbin». Исторически каталоги с такими названиями отличались тем, что исполняемые файлы в bin предназначались для всех, а в sbin — только для администраторов системы.
Со временем, впрочем, различия между bin и sbin во многих Linux-дистрибутивах стерлись: сейчас в /usr/bin можно, как правило, найти множество приложений, требующих прав суперпользователя (root) для запуска.
Подведение итогов дискуссии в рассылке Fedora по вопросу использования /usr/bin в качестве единого системного каталога для исполняемых файлов можно найти в сообщении Леннарта Поттеринга (Lennart Poettering). Леннарт, известный в Open Source-сообществе как автор PulseAudio и systemd, работает в Red Hat.
Ожидается, что уже в релизе Fedora 17, запланированном на май 2012 года, пользователи увидят следующие символические ссылки:
- /lib -> usr/lib
- /lib64 -> usr/lib64
- /sbin -> usr/bin
- /bin -> usr/bin
- /usr/sbin -> bin
Постоянная ссылка к новости: http://www.nixp.ru/news/11483.html. Дмитрий Шурупов по материалам h-online.com.
- На замену syslog предложен новый демон journald 6 7 23 ноября 2011 г.
- Fedora 17 — новая версия популярного Linux-дистрибутива 6 29 мая 2012 г.
Бен Коттон из Red Hat предложил маркировать и удалять пакеты-пенсионеры при обновлении Fedora
1 3
Доступен традиционный серверный релиз Fedora 27, а проект Modularity будет переосмыслен
15
Файловая система btrfs объявлена устаревшей для Red Hat Enterprise Linux
1
Для Linux-дистрибутива Fedora (24, 25 и 26) добавили поддержку snap-пакетов 1
Fedora 18 будет хранить временные файлы из /tmp в оперативной памяти 5 11
Файловой системой по умолчанию в Fedora 16 станет btrfs 2 18
Последние комментарии
-
OlegL, 17 декабря 2023 года в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
DevOps as a Service from Palark
ну вообще-то в последнее время в /bin/ /sbin/ /lib/ и пр. помещали файло для минимально функциональной системы — те чтобы можно было загрузиться и примаунтить usr и прочее. То как я использую это фичу, вызывает у мну недовольство такой инициативой… А как-же initrd? там тоже такое понаделают?.. Надеюсь, им никто не даст пропихнуть в LSB эту лажу…
Я не поленился и сходил по ссылкам. В принципе, вопрос полезности этого разбивается на два подвопроса:
1. надо ли сливать в одну кучу bin и sbin?
2. надо ли разделять бинари из / и из /usr?
Против первого, возражений по-моему особо-то и быть не может. sbin, вообще, это от static bin, то есть там, согласно названию, должны хранится статически скомпонованные бинари, но… кто-нибудь подсчитывал сколько из бинарей sbin сегодня статически скомпонованы? Мне кажется, что если и есть такие, то их очень немного. А в плане использования системы, как по мне так удобнее слить их воедино. Не надо будет в PATH добавлять себе /sbin и /usr/sbin.
Со вторым сложнее, но основная идея, как я её понял: сегодняшняя система без примонтированного /usr может и не загрузиться. Ну, скажем, инициализация udev, со всеми там udev/rules.d может потребовать бинарей из /usr. Наверное это всё можно решить, если разработчиков дистрибутива напрячь как следует, но судя по предстоящим эволюциям федоры, им это надоело. ;)
А то, что /usr на отдельном разделе, и в корне нет бинаря mount, так это легко решается при помощи initrd.
В общем я склоняюсь к тому, что мысль эта здравая. Лишний повод начать использовать initrd.
А что можно без initrd было? (С) :D
Когда маунтится локальные fs, pivot root уже сделан, так что mount в initrd не поможет.
> сегодняшняя система без примонтированного /usr может и не загрузиться.
Это все от лени. Всмысле лени мантейнеров. Никогда такого не встречал. И вообще, udev стартует РАНЬШЕ чем стартует mdadm и раньше нежели стартует lvm (априори раньше — с какими девайсами оно работать будет, если нету еще udev-а). Те по вашему, система вообще не должна проинититься? ладно с ним с mdadm — можно сказать что это для бедных и RH они не юзають — а lvm?
Ну значит локальные fs будут маунтиться до того, как выполняется pivot_root. Это же элементарно.
Ну, во-первых, с девайсами можно работать и без udev. Попробуйте как-нибудь его отмонтировать и заглянуть в /dev. Там хлама всякого… И он не только историческую ценность несёт, между прочим. Очень оказывается полезным как раз на тот случай, когда udev запустить не удаётся.
А во-вторых, речь не о том, что стартует раньше. Ну вы сами подумайте: зачем нужны и /, и /usr? На всякий пожарный, на тот случай, если мы хотим поработать в системе, когда ещё не примонтирован /usr, так? Ну и, допустим, /usr у нас сломался и требует вмешательства извне. Мы решаем загрузить систему без /usr. И в каком бы порядке не запускались udev, mdadm и lvm, всё равно получится так, что когда будет запускаться udev использующий бинари из /usr, он начнёт ругаться матом, потому что бинари эти ему недоступны.
Ну и наконец в третьих, высказана была такая мысль: зачем в системе настакивать уровни загрузки один за другим, когда каждый следующий отличается от предыдущего лишь тем, что что-то ещё сделано, когда каждый следующий — это чуть более функциональная система по сравнению с предыдущим. Зачем это? При желании можно запихнуть в initrd все основные утилиты, которые могут понадобиться при загрузке системы. Это упрощение системы. Правда упрощение вводимое после того, как систему усложнили до той степени, что она уже не может загрузиться без ошибок без подключенного /usr.
А, кстати, вспомнил ещё один аргумент в пользу: если все бинари с библиотеками затолкать в /usr, то после этого легко можно маунтить /usr с опцией ro, во имя пущей безопасности, а / оставить rw, ради возможности работать с /etc, /tmp, /var и пр. И при этом, _все_ бинари будут стопроцентов ro.
А вообще… Что-то последнюю неделю, я поимел десяток жарких споров в интернетах. На совершенно разные темы. Начиная с IT, продолжая математикой, заканчивая лингвистикой и психологией. Мне хочется отдыха от этих трудов ратных. Сходите по ссылкам приведённым в новости. Особенно обращаю ваше внимание на вторую. Там перечислены по пунктам все доводы в пользу этих изменений в структуру федориной фс. Пункты нумеруются английскими буковками, и по-моему последний пункт «занумерован» буковкой «n». То есть там есть что почитать.
Вот если бы вы почитали эти пункты, обдумали бы их, скомпилировали бы в три-четыре пункта, а потом каждый из этих четырёх пунктов раскритиковали бы здесь в пыль и хлам, то это было бы дело. А так наша с вами беседа больше напоминает очередной заурядный холивар ни о чём.
> Ну значит локальные fs будут маунтиться до того, как выполняется pivot_root. Это же элементарно.
Хотя-бы ман почитал что-ли… И посмотрел как бутится система с initrd… А потом уж говорил непонятно что…
> Попробуйте как-нибудь его отмонтировать и заглянуть в /dev. Там хлама всякого…
$ mkdir /tmp/dev
# mount -o bind / /tmp/dev
$ ls /tmp/dev/dev/
console full loop0 loop3 loop6 null pts ram1 ram12 ram15 ram3 ram6 ram9 stderr tty xconsole
core initctl loop1 loop4 loop7 port ram ram10 ram13 ram16 ram4 ram7 random stdin tty0 zero
fd kmem loop2 loop5 mem ptmx ram0 ram11 ram14 ram2 ram5 ram8 shm stdout urandom
Ну и где-же ожидаемый хлам-то?
Давайте остановимся на секунду, и подумаем: что же вы пытаетесь мне доказать? Что инженеры из редхат совершенно безграмотны, и ошибаются говоря о том, что их новый подход к размещению файлов не помешает монтировать /usr? Мне кажется, что это не так. То есть, я уверен, что вы пытаетесь доказать мне вовсе не эту глупость. Я уверен, что всем понятно и так, что если инженеры RH сказали, что они могут это сделать, то это значит, что они могут. Но что тогда вы мне доказываете? То что я не смогу смонтировать md0 не имея запущенного демона udevd? На спор могу это сделать имея под рукой лишь / смонтированный в rw, на котором нет ничего, кроме статически скомпонованных bash, mknod, mkdir и mount. Причём мне даже не важно, будут ли они лежать в /bin, в /sbin или прямо в корне фс. В качестве варианта могу справится и с таким сетапом: текстовый редактор и gcc. Даже могу при этом обойтись без glibc и ядерных хедеров: три системных вызова мне несложно и вручную написать без glibc’овых обёрток. Если вам интересно, могу поспорить и про lvm. Так даже азартнее будет, поскольку, хоть я и уверен в возможности смонтировать что-то через lvm без udevd, но всё же уверен не на 100%: никогда не интересовался тем, как работает lvm. Но подозреваю, что так же как и рейды, udevd там если и нужен, то в таких специфических ситуациях, что… Что почитай и не нужен вообще.
Или может вы хотите доказать мне что-то совершенно другое, что просто не приходит мне в голову? Но что? Мне и так, как я уже говорил и так не очень интересно спорить, но поскольку я потерял идейную составляющую этой «дискуссии», то уже даже зевать хочется. Так что давайте сначала договоримся о чём спорим, а потом, если вам так хочется, мы собственно поспорим.
Ну да. Сначала создаем себе трудности а потом героически их преодолеваем. Одной фразой большая часть вашего пред. поста… Заодно и предмет спора.
Вы о том, что сначала потерять нить дискуссии, а потом махать шашками вслепую, каждый на свою тему? Да, согласен.
И где-же я отошел от первого своего поста? Что пощуй RH себе что угодно делают косячат себе как угодно (у них и так поломана загрузка с пустым usr) а в LSB пущай не лезут? Что с тем, что они сделают — потеряется много каких возможностей? И те причины, которые они ставят как основные (можно будет смаунтить usr в ro и ДАЖЕ корень ё-мое что и так можно сделать, как на моих серваках с дебианом, расшарить usr для всех машин — а почему сейчас этого нельзя сделать и прочая хренотень) не являются для меня достаточными хотя-бы потому что я и так 90% из них в состоянии удовлетворить? А вот загрузится с пустым usr я тогда не смогу? Что initrd теперь будет под 50Мб и его надо будет пересобирать при каждом пуке в системе? Кто из нас махает шашкой перед голой коленкой?
> И где-же я отошел от первого своего поста?
Везде. Вы перечитайте свой первый пост и претензии высказанные там. Те претензии как-то сами заглохли появились новые. Новые тоже вроде заглохли, и опять вам что-то не так. А что вам вообще может понравится, хотелось бы знать? Что-нибудь кроме протеста против всего у вас есть?
Я все-таки выразил _свое_ отношение к новости. Предоставив достаточное количество аргументов. Последующее — ответы на ваши-же сообщения. И про initrd и маунт fs-ок на этой стадии, и про dev с якобы наличествующим там хламом. И про то, что аргументы RH высосаны из ихнего и только пальца, хотя вы почему-то уверены что я не читал UsrMove. У вас личная неприязнь к моим постам? Или ответ на возражение (ваше-же) является отходом от темы?
У меня? Личная неприязнь? Вы о чём вообще? Эмм…
Короче так. Я могу разложить по-полочкам сию «дискуссию», и дать ей психологическую оценку. Но я думаю, что после этого, вы действительно получите повод говорить о личной неприязни. Поэтому я предлагаю вам, просто прекратить этот бессмысленный разговор. Даже не спор, поскольку предмет спора неясен, и несмотря на то, что я об этом говорю уже несколько дней, я до сих пор не услышал формулировки этого «спора».
Вам не ясен предмет спора? Тогда зачем вы отвечали на мой комментарий? Спор вокруг <заголовок новости> или нет?
Заголовок новости о том, что rh сливает в один флакон /bin /sbin /usr/bin /usr/sbin, и о чём здесь спорить? Сливает или не сливает? Вы предлагаете поспорить о том сфальсифицировал ли Дмитрий Шурупов новость или нет? Ну давайте поспорим, только чур я на стороне Дмитрия Шурупова.
Или вы не понимаете в каких соснах я заблудился, и почему я не вижу предмета спора? Потому что я могу предполагать несколько предметов спора. Спор инициировали вы, изначально оставив провокационный комментарий, который чуть ли не обвиняет инженеров RH в безграмотности. И затем вы продолжили эту линию. И вот тогда у меня встал вопрос: аргументы в пользу чего (или против чего) я должен приводить в своих ответах вам?
Вот неполный список ответов на этот вопрос, которые пришли мне в голову:
Но я не имею никакого желания доказывать ничего из вышеперечисленного. И ничего из того, что я не стал перечислять. 1 — вообще не моё дело. 2 — откуда я могу знать? Последний дистрибутив от RH который я использовал — это RedHat 9.0. 3 — я не желаю доказывать, потому что не согласен. 4,5 — я ничего не могу сказать определённого. 6 — я в твёрдой уверенности, что «личное мнение» по-определению не может быть предметом спора.
Уж извините, но я тогда вообще ничего не понимаю… Раз не хотели ничего доказывать — ради чего начинали дискуссию… И где я словом обмолвился о некомпетентности инженеров RH? Обвинил и излишней лени — да. Не более того. И уж моему мозгу никак невдомек чем вызвано и путями какой-такой ассоциации можно было дойти до
> Вы предлагаете поспорить о том сфальсифицировал ли Дмитрий Шурупов новость или нет?
Придраться к словам, разве-что…
Ну во-первых, дискуссию начали вы, тем самым провокационным комментарием про лень майнтейнеров и тд, и тп. Появление же моего первого комментария вызвано тем, что в вашем первом были озвучены вопросы. Мне показалось, что вопросы были вызваны ленью ходить по ссылкам (очень мне понятной ленью — сам такой же), и я предложил вам скомпилированную версию того, что по ссылкам, выкинув всё менее существенное (на мой взгляд) и оставив ключевые пункты.
Или это были риторические вопросы, и отвечать на них было плохим тоном? Извините не понял.
А во-вторых, если вы не желаете понимать шуток, то я вам объясню на пальцах. Хоть и был уже печальный опыт объяснения шуток, но я надеюсь, что в данном случае всё будет не столь плохо. Итак, желая уточнить предмет спора, вы сказали следующее: «спор вокруг <заголовок новости>». Я же, хотел пояснить что это недостаточно точное определение темы спора. И чтобы это пояснить, предложил вам абсурдную тему спора «вокруг <заголовка новости>». Надеялся, что это вызовет улыбку, которая в свою очередь поспособствует взаимопониманию.
Ну вы перечитайте свои комментарии, причём постарайтесь читать их, как будто они оставлены сторонним человеком, чтобы если дело в том, что вы просто неточно выражали свои мысли, то вы бы тем не менее увидели, о чём вы говорили.
1. Вы постоянно ставили под сомнение работоспособность идеи. А если инженеры RH говорят что это можно и это уже у них работает на тестовой тачке, то какие выводы напрашиваются? Инженеры RH ошибаются?
2. Инженеры RH говорят, что так будет проще. Вы же начали с того, что обвиняли их за это в лени, хотя, по-моему, стремление делать проще — это если и лень, то позитивная. Именно из такой лени родился UNIX. То есть такая лень, которой хвалить надо, а не обвинять. Продолжили же вы тем, что поставили под сомнение сам факт того, что предложенный подход будет проще. Опять выходит, что инженеры из RH ошибаются?
3. Вообще обвинение в лени, если по-хорошему, для специалиста — это обвинение в некомпетентности. Если специалист свою лень ставит выше дела, то какой он после этого специалист? Но один специалист, может просто ошибиться, а если речь идёт о группе специалистов занятых поддержкой достаточно серьёзного дистрибутива, такого как RedHat? Они все ошибаются?
1-е могу поддержать.
2-е — это маразм. Давайте объединим /bin и /usr/bin, а то нам западло писать правила для systemd. Раз уж приняли его в федору, то пусть пишут миллион правил.
А разве пытаться запустить бинарник из отмонтированного /usr может только systemd?
Какие еще есть варианты?
> 1. надо ли сливать в одну кучу bin и sbin?
А профит -то какой от этого будет? Разве что «обычный десктопный пользователь» порадуется. Я, например, на серверах на /sbin, /usr/sbin и /usr/local/sbin вообще ставлю chmod o=, иногда оставляя возможность лазать туда определённой группе, и иногда ставлю o=x (в основном ради /usr/sbin/sendmail).
> sbin, вообще, это от static bin
Исторически — может и так (static). В реальности там лежат «админские» или «околоадминские» (system, security, s..?) программы, которые простому пользователю, не говоря уже о демонах, ни в какое место не упёрлись. И за всё то время, что я интересуюсь UNIX-like системами, я впервые услышал, что s — это static: во всех книгах и мануалах акцент ставился именно на разделении пользовательских и админских задач.
И да, в чём профит-то? Или линукс теперь — исключительно обычная однопользовательская десктоп-ориентированная система?
> 2. надо ли разделять бинари из / и из /usr?
Для начала рекомендую почитать дебиановское обсуждение этого вопроса. Аргументов и всяких нестандартных ситуаций, для которых перенос системы в /usr труднореализуем, там вагон.
lists.debian.org/debian-devel/2011/10/msg00157.html
Требовать обязательного использования initramfs тоже считаю перебором. Более того, дебианщики утверждают, что есть платформы, вообще не умеющие initrd.
Да, в своих задачах я перешёл на систему с /usr и / в одном разделе. Аргументами _для меня_ явились:
— наличие /opt, куда всякий несвободный ещё софт, совсем не входящий в базовую систему, очень любит ставиться, и моё нежелание делать для /opt ещё один раздел в стандартной системе;
— страшно сказать, гентушное расположение sshd в /usr/sbin, а не в /sbin, что, конечно, логично, но лично мне пару раз очень мешало.
Но это конкретно мои задачи, и со временем и они тоже могут измениться, и гибкости лишаться очень не хочется.
Из забавных историй: где-то в комментах народ рассуждал на тему «сейчас я могу взять базовую систему bsd в корне, примонтировать /usr из линуксового дистрибутива, и получить почти работающий самодельный Debian GNU/kFreeBSD» (уж не знаю, насколько история реальна на самом деле).
Народ также вспоминал ситуации с некоторыми домашними роутерами и некоторыми мобильниками, где базовая жутко урезанная система почти что в read-only стоит в корне, размером в четыре-восемь мегабайт, а весь дополнительный софт подключается с флэшки или по сети.
Зачем намеренно ломать совместимость, убирать традиционную гибкость, если реальных плюсов — ноль? Список аргументов видели? Там нет ни одного бесспорного, а некоторые вообще неверны по своей сути (например, про невозможность держать корень в ro).
P.S. Ещё не читал гентушное обсуждение этого предложения, но почти уверен, что в gentoo по традиции и на такую идею найдётся своя опция: что-нибудь типа «достаточно задать переменную INSTALL_MY_BINARIES_TO перед емёрджем пакета, и он встанет туда, куда вы его попросите, это можно сделать как в шелле, так и, по традиции, в конфигах в /etc/portage/install_me_to.d/» :)
А как-то мне ничего в гентушных рассылках на эту тему за последние три недели и не прилетело :)
Обсуждения на тему «/usr на отдельном разделе» случаются достаточно регулярно, а вот про смёрдживание /bin и /sbin что-то тишина..
О! Какие люди!
По-порядку.
1. Ты, как я понимаю, используешь sbin, чтобы спрятать от пользователя админские приложения, с целью повышения безопасности. Так? Но это если и повысит безопасность то против такого ламера, который даже имея эти приложения не смог бы ими как-либо навредить. Даже при большом желании. А тот кто может навредить, он может создать бинарь sshd у себя в домашней директории, повесить на него +x и запустить прямо оттуда. Причём для создания бинаря ведь необязательно иметь gcc, можно переслать по почте, через ssh, и придумать ещё мульён способов сделать это.
Такие «меры безопасности» чем-то напоминают вендовые групповые политики. Вокруг которых начинающие хакеры постоянно брызжут слюной от восторга: вроде и запрещено всё, а всегда можно обойти. Но и то, групповые политики имеют куда как больший смысл, поскольку они позволяют ограничить пользователя (пускай и далеко не любого) в весьма неожиданных вещах, например запретить ему редактировать реестр или запускать калькулятор.
В слиянии /bin и /sbin я вообще не вижу никаких минусов. Из плюсов же вижу один мааленький такой: безо всяких настроек PATH для не-root’а, без создания симлинков, можно будет использовать ifconfig, route, lspci не выписывая пути целиком. Мелочь, которая будет чуть-чуть полезной хорошо если раз в полгода, но именно эта мелочь, перевешивает моё мнение в пользу слияния.
Про обычную однопользовательскую систему не понял.
2. Дебиановское обсуждение, я почитал, но не дочитал. Не хватило терпения. Но, как бы там ни было, дебиановское обсуждение обсуждает всё это применительно к debian.
> Требовать обязательного использования initramfs тоже считаю перебором. Более того, дебианщики утверждают, что есть платформы, вообще не умеющие initrd.
Fedora работает на тех платформах? А вообще, за последние два года, наполненных для меня постоянно ломающимися жёсткими дисками, я пожалел и пожалел не раз о том, что от меня никто не требовал обязательного использования initrd.
> Зачем намеренно ломать совместимость, убирать традиционную гибкость, если реальных плюсов — ноль? Список аргументов видели? Там нет ни одного бесспорного, а некоторые вообще неверны по своей сути (например, про невозможность держать корень в ro).
Мне кажется, что всё о чём говорят ребята из RH — это о том, что так будет проще. Естественно применительно к RH. Кстати, если память мне не изменяет, про _невозможность_ держать корень в ro они не говорили, они говорили, что если слить всё в /usr, то будет проще держать бинари под флагом ro. Корень можно держать в ro, но придётся позаботиться о возможности писать /tmp и /var. А если речь о федоре, то быть может и в /etc. Проще же просто перекинуть бинари в /usr.
Про совместимость, опять же туманно. Совместимость с чем? С железом? Я не думаю, что Fedora на этом потеряет в совместимости. Специально слазал на страничку требований федоры к железу, и не нашёл там ни слова о том, что можно иметь процессор не x86/x86_64. Хотя, мне почему-то казалось, что оно работает ещё и на PowerPC. Но как бы там ни было, PowerPC вряд ли входит в список тех платформ, на которых невозможно использование initrd.
Про гибкость они написали: федора и без слияния не грузится без /usr. Точнее, как я думаю, грузится, но с кучей ругани.
> почти уверен, что в gentoo по традиции и на такую идею найдётся своя опция
=)
За что я и люблю генту. Споры не нужны, каждый делает так, как ему удобнее.
> О! Какие люди!
>
Да, слёг тут с ангиной, и под температуру захотелось фигнёй помаяться :)
Как жизнь? :)
> Ты, как я понимаю, используешь sbin, чтобы спрятать от пользователя админские приложения
>
А ещё список установленных приложений. Конфиги. Настройки и модули ядра. /proc и /sys. И юмаск по умолчанию 0027 :) Даже TMPDIR у меня персональные у каждого пользователя. Одним o= на sbin дело не ограничивается. Идея простая: если для задач что-то не требуется, то и не надо это что-то давать.
> А тот кто может навредить, он может создать бинарь sshd у себя в домашней директории, повесить на него +x и запустить прямо оттуда.
>
Не сможет. На home обычно noexec, так что только скриптами, только скриптами..
А даже если и сможет _запустить_, есть ещё пользовательские ограничения на исходящие коннекты и на бинд локальных сокетов:
kernel.grsecurity.socket_server
если же он демон — он у меня обычно ещё и в персональном чруте, где вообще мало что есть.
> можно будет использовать ifconfig, route, lspci
>
пользователям на моих серверах они без мазы, доступа в /proc и /sys (помимо своих личных пидов и базовых вещей) всё равно у них нет.
> В слиянии /bin и /sbin я вообще не вижу никаких минусов. Из плюсов же вижу один мааленький такой: безо всяких настроек PATH для не-root’а, без создания симлинков, можно будет использовать ifconfig, route, lspci не выписывая пути целиком. Мелочь, которая будет чуть-чуть полезной хорошо если раз в полгода, но именно эта мелочь, перевешивает моё мнение в пользу слияния.
>
А может всё-таки лучше в одном bashrc PATH поправить, чем в половине пакетов системы пути установки файлов?
> Корень можно держать в ro, но придётся позаботиться о возможности писать /tmp и /var.
>
Естественно. Но вынесение /tmp и /var на отдельный раздел — задача, смысл которой гораздо более понятен, чем вынесение /usr. Только я для себя выношу ещё /var/tmp.
Логика простая. Всё, что должно изменяться, не должно запускаться. Оно по возможности должно лежать на разделах с noexec,nosuid,nodev.
Всё, что должно запускаться, должно быть в read-only.
В /etc, кстати, лежит весь инит, он не бинарный, он скриптовый, но это логика работы системы, следовательно /etc тоже должен быть в read-only, и перемонтироваться в rw только на время каких-то изменений конфигурации (что случается крайне редко на реально работающих серверах, не говоря уже про всякие мелкие системы). В Fedora это может измениться с переходом на systemd, это да… А есть ещё всякие /etc/cron.daily..
А, да, ради нормального синка дерева портажей, его я тоже перенёс из /usr/ в /var. Мне почему-то кажется, что там оно гораздо логичнее смотрится.
Ну и это. На всякий случай. Под «пользователями на серверах» я понимаю как обычные шелл-аккаунты, так и всевозможных демонов.
> Про совместимость, опять же туманно. Совместимость с чем? С железом?
>
С традициями UNIX. Касался бы вопрос чисто федоры — мало кого бы тема волновала. Но следом ведь будет Red Hat, за ними повторят ещё несколько дистрибутивов, а потом они и правда придут к тому, что по следующему стандарту в корне у тебя вообще больше не будет ни директорий, ни симлинков /bin, /sbin и /lib..
> так будет проще. Естественно применительно к RH.
>
Для редхата — конечно, они работают исключительно в своей нише.
Если бы только ими это ограничивалось, разговор можно было бы заканчивать, не начиная: что они там пилят чисто для себя, это их дело..
Однако, как видишь, дебианщики уже вовсю обсуждают… Дурной пример заразителен..
> Как жизнь? :)
Да ничётак.
> Логика простая. Всё, что должно изменяться, не должно запускаться. Оно по возможности должно лежать на разделах с noexec,nosuid,nodev.
> Всё, что должно запускаться, должно быть в read-only.
> [...]
Ну у тебя, я смотрю, сетап до ужаса параноидальный. И кроме того, если уж речь про такую параноидальность… А может лучше для каждого демона создать своё chroot-окружение? Ну или может для каждой группы из /etc/group. Или может не для каждой.
Но это ладно, это уже несколько оффтоп, по теме же, тут сложно не согласиться с тем, что собирание в одну кучу /bin и /sbin лишь породит проблем.
> Однако, как видишь, дебианщики уже вовсю обсуждают… Дурной пример заразителен..
Мало ли что они обсуждают. Как я понял, идея завязать дебиан на initrd не проканает. И правильно. То есть, если рассматривать это нововведение редхат применительно к GNU/Linux вообще, то на мой взгляд, все аргументы против, они примерно как и аргументы «за» от редхата — есть какие-то плюсы, но есть и минусы. Что и куда перевесит зависит исключительно от красноречивости спорщиков. Все аргументы такие, кроме одного: завязка на initrd действительно может быть неудобна. А как говорят дебианщики, она, ко всему прочему, не всегда работает. И я сильно сомневаюсь, что они начнут закидывать бинари из / в /usr.
Другое дело, что слить в один флакон bin и sbin они могут. Я вроде не видел там в обсуждении возражений против этого. Правда и до конца я не дочитал.
> Да ничётак.
пить бум? ;)
> А может лучше для каждого демона создать своё chroot-окружение?
ну так так и есть обычно. если не в жуткой спешке проект сдавался.
> Ну у тебя, я смотрю, сетап до ужаса параноидальный.
да как бы это, по-моему, вполне обычная вещь: «код и данные должны лежать отдельно». Я такого по возможности требую даже от web-кодеров.
>> Всё, что должно запускаться, должно быть в read-only.
тут даже имелось в виду не столько «запускаться», сколько по возможности вообще «исполняться».
> > Ну у тебя, я смотрю, сетап до ужаса параноидальный.
> да как бы это, по-моему, вполне обычная вещь: «код и данные должны лежать отдельно». Я такого по возможности требую даже от web-кодеров.
Да я в более общем смысле. /proc закрыт. Но и тем не менее всеми силами прячем ifconfig. И я не к тому, что это перебор — нет. Так и надо, просто я давненько видать не читал «хакерских» success stories, и подзабыл, что самым писком является взлом, когда в системе нет ни одной серьёзной дыры, но много маленьких, даже не дыр, а так, микротрещин. И конечный результат достигается в десяток маленьких шагов, каждый из которых даёт так мало, что даже рождаются сомнения в целесообразности этого шага, но и всё же, каждый шаг приближает к конечной цели.
> А тот кто может навредить, он может создать бинарь sshd у себя в домашней директории, повесить на него +x и запустить прямо оттуда.
На таких есть TPE (Trusted Path Execution) — не позволяется запуск бинариков из папки куда может писать не рут или запускающий входит в специальный GID (root и члены указанного при сборке ядра GID проходят проверку всегда удачно). Обработку этого GID можно инвертировать (те ограничение только на членов этой группы)
> Дебиановское обсуждение, я почитал, но не дочитал. Не хватило терпения. Но, как бы там ни было, дебиановское обсуждение обсуждает всё это применительно к debian.
Да в том и дело, что RH слишком большой игрок в мире Linux. И хочешь не хочешь любой дистр пересекается с RH.
> За что я и люблю генту. Споры не нужны, каждый делает так, как ему удобнее.
Оно-то конечно хорошо. Но стандарты очень упрощают жизнь. Грубо говоря, если я буду настраивать debian-овскую машину используя только debian-way, то ее сможет поднастроить любой админ, рулящий debian-ом. А вообще «Любой физик на любом языке напишет на Фортране» (С) :D
Да, про TPE я почему-то не сказал, он тоже обычно есть.
А я сюда так… поздороваться с Сигизмундом зашёл :-)
ПРЕВЕД!!! :) Я на самом деле раз в неделю-то стабильно захожу, новости и обсуждения просматриваю.
Мы тут, кстати, пару месяцев назад даже пива попить смогли с Dark_Savant’ом и DimkaS’ом, у меня к ним несколько вопросов по работе было.
Лучше уж сразу переименовать в /Program_Files
Или вовсе отказаться от каталогов.
Нет, чтобы наоборот навести порядок…
Program Files — это несколько иное. Это когда на каждую софтину свой /usr, причём с нестандартным деревом директорий. Здесь же речь ровно об обратном, речь о том, чтобы уменьшить количество мест, где надо искать тот или иной файл.
А как это повлияет на скорость, в смысле в одном каталоге будут сотни файлов?
Близко к «никак».
А можно пояснить — почему не повлияет? Спасибо.
Вот что у меня в системе:
У всех будет по-разному, но примерный порядок ясен. Объединение не приведет к значительному росту файлов в /usr/bin.
Негативные изменения в скорости доступа к /bin, /sbin, /usr/sbin будут проявляться, потому что теперь эти обращения будут «переправляться» к более «массивному» /usr/bin, но… вы замечали существенные лаги при работе с нынешним /usr/bin? Вот так и будет.
Можно еще почитать что-нибудь такое:
Спасибо за инфу. Было интересно почитать.