в процессе <font color=«blue»>обсуждения</font>, возник вопрос о 'нормальности' системы по расположению утилит.
потому, что бы не вдаваться сильно в оффтопик, продолжим тут.
Последние комментарии
-
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
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Отсалось определить критерии нормальности системы ;)
На самом же деле, я всего лишь намекнлу на то, что для универнсальности решения вместо пути до утилитки 'arp' можно использовать, наример, конструкцию:
Уверен, Genie это понял. А ты чего-то не к месту о какой-то нормальности системы заговорил…
:)))
я вставил как есть из окна rxvt. переменная PATH у меня /sbin:/usr/sbin не содержит, так что приходится указывать путь явно.
ну да и сам же понимаешь, что главное — показать принцип. в приведённой мной команде и её выводе по большому счёту и grep не нужен. и скобки тоже. :)
и вообще, туда можно было воткнуть вызов awk и выделить только один MAC. чтобы никаких лишних слов не выводило. :)
ну да. просто про nmap ты так сказал без уточнения. возмёт кто ещё и поверит. а потом будут непонятки.
да нет. тут как бы это сказать. arp всё же утилита системная, и в доступе простым пользователям по умолчанию ей, вроде как, делать не положено. fdisk же ты не дашь кому другому? ;) понятно, что по сути даже если и дать — то прав не хватит его деструктивно использовать, однако…. оно для повседневной деятельности простым пользователям излишне.
Ну, ладно, ладно.. К этому придираться больше не буду ;)
Дык, это ж из определения ясно ;). А-то и arpwatch с твоим способом проверят, а потом будут непонятки.
У нас каталоги системных утилит ограничиваются только /usr/sbin?
что-то не совсем понял про 'мой способ’… ну да ладно :)
почему же? ./sbin есть ещё… :)
отчасти разделение по расположению в /bin::/sbin или /usr/bin::/usr/sbin диктуется разделением по утилитам, необходимым для минимальной работы системы и для полноценной работы
бывает, что /usr монтируется отдельным разделом. взяло и упало fs там.
поднимать — нужны утилиты из /bin::/sbin.
всем же программам, понятное дело, в /bin::/sbin делать явно нечего. их-то — в /usr/bin::/usr/sbin
*arp* явно не относится к программам, требуемым для начального запуска системы :)) но — она не пользовательская — потому — в /usr/sbin
хотя, наверное надо пойти и какой документ офицальный на это дело найти… вспомнить бы ещё, где его искать… :)
Завязка на шелл ? Фтопку! which решает. ;-)
Товарищ, существование у отдельных пингвиноводов единственного раздела - это не повод говорить за всех.
Пойми, наконец, что существует базовая часть системы и пользовательская, а также софт может линковаться статически и динамически. Если ты пытаешься запустить софт, библиотеки для которого находятся на несмонтированном разделе — опаньки.
man hier в нормальной системе. :-)
а-а-а. точно.
хе-хе. :)
в общем, сильно я не ошибся.
да пожалуйста ;).
Ты это к чему вообще?
Ты так и не сказал, что значит «нормальная» система.
Да ладно тебе ;). Хорошо. «способ, о котором говорил ты с использованием утилитки arp» ;).
Ну, вот, ещё и /sbin. У кого-то 'arp' лежит именно в /sbin.
У тебя в /sbin лежит ровно то, что необходимо «для начального запуска системы"?
Просто разные дистрибутивостроители подходят к размещению утилит в каталогах /sbin, /usr/sbin каждый по-своему. И дело тут вовсе не в «нормальности» системы.
А что за документ?
Мне кажется, это ясно и a priori. ;-)
О существовании других ОС и каалогов /usr/local/{s}bin. ;-)
Это не объяснение.
И что? Ты мысль-то развивай, а-то одни недомолвки, которые «приходится домысливать, а потом быть обвинённым в своих домыслах» (с).
Что привязался ? BSD это. ;-)
Какие мы злопамятные. Кто ж тебя таким сделал ? :-)
Есть несколько разделов. При попытке выполнить команду оказывается, что необходимая .so на ходится на несмонтированном разделе. Прояснение наступило ? :-)
Т.е. все критерии «нормальности» системы сводятся к тому, что она должна быть BSD? Ну, тогда я с тобой не согласен.
Дальше развивать данную тему в этом направлении не вижу смысла, если только не будут приведены аргументы, типа: «нормальная система — это система, которая удовлетворяет следующим требованиям: 1)… 2)… 3)… » — и далее по пунктам эти самые требования, для которых, надеюсь понимаешь, что одного твоего «BSD» мало.
Ну, находится она [библиотека] на несмонтированном разделе, и что? Проблема его смонтировать?
Причём тут «нормальность» системы и arp, в частности?
Надеюсь NetBSD?
Необязательно. :-) Почему именно Net ?
Сдох он или грязный, а проверка занимает существеное время. Твои действия ?
Базовому софту — место на /. Пользовательскому — на других, ибо иногда приходится использовать опцию noexec.
Ради бога. Все знают, что решает соляра. :-)
Конечно, критерии нормальности у всех разные. У меня в локалке — около 40 машин с W2k Professional. А что ? Нормальная система. :-)
Это ты про тот раздел, на котором находится необходимая для какой-то абстрактной программы библиотека? Ну так если сама программа будет находиться на том же разделе, то ей это ничем не поможет. Раздел-то сдох (или «грязный»).
Вот так бы сразу — хоть какой-то аргумент. Но дело всё в том, что подход к базовому софту, опять же, у всех разный. Для меня, например, и утилита 'arp' базовая, и ей никак нельзя присваивать noexec.
P.S. на самом деле, фраза: «осталось определить критерии нормальности системы», — с которой начался весь этот флейм, была лишь для того, чтобы ты сделал для себя вывод, к которому, кстати, сам и пришёл в последствии: «критерии нормальности у всех разные.».
А если нет ?
Про noexec я упоминал в отрыве от контекста arp.
Хорошо-хорошо. :-)