продолжение темы про принтер и ядро 3.12.1

Посмотри /etc/modprobe.d/blacklist.

Посмотри /etc/modprobe.d/blacklist.

Ядро монолитное без модулей.

Ага перечитал, сорри, тогда смотри на опакеченные драйвера. В гугле был? Есть несколько решений с установкой недостающих пакетов и правильными юзами. С такой машинкой дело не имел, но можно предположить, что в новых ядрах выпилен нужный функционал/изменён алгоритм, ввиду наличия оного в отдельных пакетах.

В гугле был?

Гугл говорит что у cups с новыми ядрами (какие версии не знаю) по usblp с принтерами какие то проблемы. Не знаю даже что и делать..........

Буду в гугле искать решение.

откатить ядро на старое (3.0-3.8)?

Ядро монолитное без модулей.

ССЗБ?

ССЗБ?

Не совсем понял что имелось ввиду? Просто ядро версии 3.12.1 собираю его без модулей монолитно.

Последнее вышло 3.12.2

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

Так что Вы - самый настоящий буратино :)

splix установлен?

А как же серверы с запретом подгрузки модулей ядра? Всё, теперь нельзя запретить??

А как же серверы с запретом подгрузки модулей ядра? Всё, теперь нельзя запретить??

Если у Вас простая конфигурация оборудования и софта, то да. А если Вы используете спец оборудование, или спец фс (ceph, xtremefs, zfs и другие) или блочные устройства (bcache, flashcache), либо спец фитчи (типа серверных приложения уровня ядра а-ля lustre, NFS) - то ппц. Даже с FUSE уже фигово, т.к. при любых проблемах его просто так уже не выгрузить и заново загрузить. Даже не все драйвера оборудования можно вообще скомпилить монолитно, не говоря уже о том, что они нормально (и с пол пинка) будут работать. Плюс если Вы хотите получить реально большое количество поддерживаемых ФС, псевдоустройств, датчиков и другого оборудования, то Ваше ведро будет весить под сотню. И, если Вы его бутите не напрямую через UEFI, а через загрузчик, то это будет очень тормозно (потому что загрузчик часто работает через API BIOS'а, либо через свои тормозные костыли).

Вообще это решается через ограничение количества модулей, использования HG для безопасности (типа защиты от разыменования указателей и переполнения буферов в ведре и т.п.), использовать модулей с ЭПЦ, IMA. При помощи SELinux можно заблокировать подгрузку модулей, а потом заблокировать подгрузку политик SELinux в текущей загрузке.

Ну ещё там всякая виртуализация (за исключением ксена). ПО, которое при своей инициализации проверяет, загружен ли модуль ведра, если нет, то грузит (где оно валится с тем, что модуля нет)(соответственно, у нас API из ведра к этому приложению от его модуля уже торчит, но работать приложение не будет) (причём дофига такого ПО) (с ходу могу привести реализации SCSI-таргетов в линуксе, менеджеры распределены ФСок, dahdi). Проприетарное ПО. Внешнее ПО (flashcache, bcache, btier, куча ФСок сетевых, virtualbox, dahdi и другие). Часть драйверов оборудования конфликтуют между собой, для части оборудования могут быть написаны разные драйвера. Может потребоваться загрузить модуль с вербозом или спец фитчей без перезапуска системы.

И не забывай, что даже если ты патч для ПО сделаешь, то сам модуль может быть не предназначен для старта сразу с ведром (например, ему нужна уже сразу взрослая система, т.к. он лезет в сеть или открывает файловые дескрипторы), также может не уметь читать параметры из kernel options, а только параметры, указанные при modprobe-загрузке.

Так что (даже если тупо посмотреть на все дистрибутивы) монолитное ведро - это уже удел всяких бзднунов и их идеалогии (типа «ну у нас же не какой-нибудь линукс с его 100500 строками кода в ведре и куче аудиторов, у нас тут мейнейнерам нужно войну и мир написать, чтобы они патч из 15 строк включили в релиз, который раз в 100500 лет выходит» (если не ошибаюсь, нормальных средств автообновления бздуны так и не написали. поправьте меня), «ну у нас монолитное ведро, значит модуль-троян не подгрузят» и «ну у нас же не линукс, у нас openbsd/netbsd, система, которая изначально разрабатывалась безопасной. ну и что, что нас никто не поддерживает, нет аудиторов, и разрабатывают систему 2,5 анонимуса, переписывая код из линукса, ну и что, что у нас старое ПО, и нормальный менеджер пакетов появился год назад, ну и что, что мы не смогли бекпортировать в своё старомодное говнище portage из gentoo, из-за чего у нас половину установки пакета нужно делать вручную, ну и что, что мы не осилили IMA, нормальный MAC, современную защиту памяти и виртуализацию, TrustedBoot и другие технологии безопасности, зато у нас есть монолитное ведро, в которое никто ничего не подгрузит» (только мы манулы не читаем, а только 3.14здим про безопасность, а система из коробки голой жопой к миру повернута, поэтому мы не заблокируем доступ в памяти через псевдоустройство, да и своё монолитное говноведро на RW-устройстве разместим и проверять до загрузке его ЭЦП не будет) ).

http://en.wikipedia.org/wiki/Security_theater

Просто нужно понять, что обеспечение безопасности - это очень комплексная мера. И если ОП использует монолитное ведро, при этом не блочит доступ рута к памяти, не сливает логи (и не анализирует) на внешний сервер в RT-варианте, не проверяет систему на подмену бинарников, не использует MAC или концепцию «один сервер - одно приложение», дает рутовый доступ разработчикам на боевой сервер или даже FTP-доступ, подключает левые ppa ( :) ) и т.д. - ну это просто «стиль пьяного бздуна». У них тоже принято какие-то непонятные и необъективные доводы строить вокруг своего говна мамонта, которое интересно сейчас только тем, что оно стабильно может работать с ZFS, при этом давая больше свободы и меньше гемора, чем солярка. Но, ИМХО, проще использовать виртуализацию, либо отдельный сервер под солярку+ZFS+NFS и забыть об этом. А всякие их новые разработки, типа хаммера никому не упёрлись, потому что они совершенно не enterprise level (дай б-г до бета-фсок линукса дотягивают), документации нет, опыта использования на форумах нет.

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

А как же серверы с запретом подгрузки модулей ядра? Всё, теперь нельзя запретить??

А что, в этом есть какой-то смысл? Ну, кроме повышения уровне красноглазия.

Не поймите меня не правильно: я не против монолитного ведра. Например, когда Вам нужно запустить виртуальную машину с nginx, mysql, apache2, tomcat, postfix, dovecot, exim4, nagios и т.п. Тут точно не будет никаких проблем ни в плане поддержки оборудования, ни в плане требований ПО. Только тут вопрос в том, что часть средств безопасности линукса с монолитным вердом не работают, либо им на каждый пук нужна перезагрузка. Но, если они не будут использоваться (а, вероятно, так и будет), то монолитное ведро может иметь смысл. Только не забывайте, что обычная инфраструктура (да тот же initrd) предусматривают наличие модулей (хотя, вероятно, будут и без них работать).

И не забывайте, что в случае выше, нужно использовать всякие fail2ban по ломлению на несуществующие страничники или рассылки несуществующим пользователям, использовать всякие mod_security, naxsi, php под отдельными юзерами, выполнение только на определенную папку, куда из юзеров скриптов доступ на запись запрещен и т.д.
И вообще, желательно, использовать приложения, которые были с hardened toolchain скомпилены. :)

А ещё об операционных издержках монолитного ведра не забудьте:
1. Решение проблем, которые из-за него возникают.
2. Простои, этим вызванные.
3. Необходимо поддерживать 2 ядра (обычное и монолитное), если у Вас развитая инфраструктура.

ktulhu666

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

Я всё время на серверах и на десктопе использую монолитное ядро без рам диска, проблем никогда не возникало.

Вы весьма месье :) Вероятно, Вы никогда не использовали multipath, LVM, шифрование, загрузку по сети и другие фитчи. И с виртуализацей не работали. И проблем с повреждением фс у Вас не было. Кстати, а fsck как у Вас делается? Он, обычно, с initrd-имиджа загружается.

Вернее возникло две проблемки: проблема с печатью и проблема с загрузкой по UUID.

Вероятно, Вы бутитесь через /dev/sda2 или что-то вроде этого. Тогда Вы вдвойне месье, т.к. можете из-за ставленной флешки или разного времени инициализации нескольких HDD внезапно не загрузиться.

Вы никогда не использовали multipath, LVM, шифрование, загрузку по сети и другие фитчи. И с виртуализацей не работали. И проблем с повреждением фс у Вас не было. Кстати, а fsck как у Вас делается? Он, обычно, с initrd-имиджа загружается.

multipath, LVM, загрузку по сети, виртуализацию не использовал - по работе как то не приходилось.

Шифрование использовал. fsck прекрасно работает без рам диска.

Вероятно, Вы бутитесь через /dev/sda2 или что-то вроде этого. Тогда Вы вдвойне месье, т.к. можете из-за ставленной флешки или разного времени инициализации нескольких HDD внезапно не загрузиться.

да загружаюсь через /dev/sda2 ну и что в этом такого. Проблема загрузки по /dev/sda2 возникла у меня только тогда когда я попытался сделать систему на носимом выносном диске подключеном по usb так как заранее не известно как этот диск бедет инициализирован. В других случаях проблемы не вижу, мешает флешка - отключите её и загрузитесь, если нужно что бы она была постоянно включена - включите её определите как при этом определяется диск, впишите его и загружайтесь. Никогда не видел что бы постоянно включённые диски меняли свои sda, sdb и т. д.

PS. Точно утверждать не буду но в инете читал что в последних версиях ядра BSD в это ядро был всунут init!!!! Если init в ядро всунули..........!!!!!!!!!!

Кстати на встраиваемых системах не то что бы ядро монолитом делали, а как раз во многих случаях вообще делают всё что нужно в виде одного бинарника......!!!!

всё что нужно в виде одного бинарника......!!!!

имею ввиду всё вместе с ядром.

ktulhu666

Не пойму почему вы прицепились к этому монолиту. Я ничего такого не вижу и в модулях. В каком то случае нужны модули, в каком то рам диск (стоит дописать в ядро кусок для определения UUID и вот уже для данного случая рам и не нужен) Я привык собирать монолит, не преодолимой необходимости в модулях не возникало, если бы возникла - собрал бы с модулями. Монолит или модули в этом не вижу даже причины спора.

Я привык собирать монолит

Переучивайтесь. Современные реалии такого недопускают. Читайте выше.

Монолит или модули в этом не вижу даже причины спора.

А я вижу. Админа, который в ынтерпрайзе бы пытался внедрить монолит (кроме оооочень нетипичных случаев) да ещё и без initrd, погнал бы ссаными тряпками из компании. :)

Современные реалии такого недопускают.

А я вижу. Админа, который в ынтерпрайзе бы пытался внедрить монолит (кроме оооочень нетипичных случаев) да ещё и без initrd, погнал бы ссаными тряпками из компании. :)

Это только ваше субъективное мнение.

multipath, LVM, загрузку по сети, виртуализацию не использовал - по работе как то не приходилось.

Крутая у Вас работа, что могу сказать.

Шифрование использовал. fsck прекрасно работает без рам диска.

Это как? Поделитесь. Или Вы не про рутовый раздел? У Вас ведро само пароль спрашивает при загрузке?

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

Вы себя то сами читаете, какой бред Вы предлагаете? Вы, случае не с БСД на слаку слезни? У них там тоже ещё идеи из конца 80-х летают в воздухе. По поводу смены имен дисков: видел и не раз. А для серверов с 8+ HDD, virtual storage через iLO/IPMI BMC или для FC-систем - это вообще обычное дело.

да загружаюсь через /dev/sda2 ну и что в этом такого.

Выше смотрите.

Кстати на встраиваемых системах не то что бы ядро монолитом делали, а как раз во многих случаях вообще делают всё что нужно в виде одного бинарника......!!!!

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

Это только ваше субъективное мнение.

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

Спор бесконечный, причём я считаю что предмета спора по сути и нет.

Но вот этого я не понял:

Это как? Поделитесь. Или Вы не про рутовый раздел? У Вас ведро само пароль спрашивает при загрузке?

Насколько я понял у вас закриптован рутовый раздел (предполагаю что модули на нём - может конечно ошибаюсь) тогда мне не понятно каким образом ядро загрузит модули с криптованного раздела.

Насколько я понял у вас закриптован рутовый раздел (предполагаю что модули на нём - может конечно ошибаюсь) тогда мне не понятно каким образом ядро загрузит модули с криптованного раздела.

Не совсем понятно, за что у Вас одна звезда, если такие глупые вопросы задаете. Модули и скрипты (которые спрашивают пароль и дергают cryptsetup, а тот dm-crypt) в initrd.

Не совсем понятно, за что у Вас одна звезда

Мне её дали по блату :)