Next
Previous
Contents
(Alex Kanavin, адрес выше,
Alexey Mahotkin)
Начнем с официальной серии ядер, выпускаемых непосредственно Линусом
Торвальдсом. Прежде всего, надо разобраться, что такое стабильные и
нестабильные ядра (stable и development) и как они нумеруются. Пусть имеется
ядро версии a.b.c
- a - это основной номер версии. Меняется он раз в несколько лет, как правило,
когда нестабильная серия с очень существенными изменениями становится
стабильной.
- b - это patchlevel. Именно он определяет, является ли данное ядро стабильным
или нет. Если он четный - ядро стабильное, если нечетный - нестабильное.
Числа a и b в виде a.b называется серией ядер.
- с - это sublevel. Он определяет номер ядра в серии.
Официальные ядра в виде исходных текстов можно скачать
с
ftp://ftp.kernel.org и его многочисленных мирроров (российский:
ftp://ftp.ru.kernel.org, но им лучше не пользоваться, так как он
не миррорит .bz2, если вам нужен именно российский миррор, то попробуйте
ftp://ftp.rmt.ru/,
ftp://ftp.chg.ru/Mirrors/ftp.kernel.org/ или
http://ftp.chg.ru/Mirrors/ftp.kernel.org/).
[пользуясь случаем, хочу передать сообщение для
ftp://ftp.chg.ru
,
ftp://ftp.ru.kernel.olg и других официальных россйских
мирроров: если уж вы миррорите, например,
redhat, то делайте это целиком и каждый день, а не раз в месяц кусочками.
А то апдейты у вас появляются через месяц после того, как они были выложены
на ftp.redhat.com, да и то - только к последней версии. Ну и кому нужен
такой "официальный" mirror? Взялись быть зеркалом - делайте это как следует,
не можете - откажитесь.]
Кроме полных исходных текстов ядра там же можно найти патчи - значительно
меньшие по размеру файлы, позволяющие превратить исходники версии a.b.c в
исходники версии a.b.c+1 c помощью команды patch. Эти же патчи ходят по
файлэхе usyslnx.
Стабильные ядра предназначены для широкого использования и проблемы при
их использовании или компиляции встречаются нечасто. Как правило в
стабильных сериях от версии к версии только исправляются ошибки и
добавляются драйвера, не требующие изменений в самом ядре и хорошо себя
зарекомендовавшие. Стабильные ядра можно безбоязненно обновлять, не
трогая прочий софт - если вы остаетесь в рамках одной серии, проблем
возникнуть не должно. (По крайней мере в теории, на практике, возможно,
придется вернуться к старому ядру и подождать выхода еще одной версии.)
Новые версии выходят нечасто - примерно раз в месяц, и реже.
Нестабильные ядра, наоборот, не предназначены для использования
массами. Это полигон для тестирования множества разнообразных возможностей,
только появившихся и еще не готовых для использования никем, кроме их
собственных разработчиков и людей, чье хобби - забавляться с нестабильными
ядрами. Здесь от версии к версии может меняться очень многое и правильную
работу никто не обещает (впрочем, то же относится и к стабильным ядрам, но
в менее "жестком" смысле). При их использовании нужно быть готовым ко всему.
Прежде всего к тому, что ядро просто не скомпилируется. Потом оно может не
загрузиться, зависать, портить файловую систему и вообще всячески глючить.
Кроме того, может начать глючить софт, взаимодействующий с ядром напрямую.
Нестабильные ядра выходят гораздо чаще стабильных - иногда несколько новых
ядер в неделю.
Как нестабильная серия становится стабильной и наоборот ? Очень просто:
в какой-то момент Linus Torvalds объявляет т.н. feature freeze, после
чего к включению в нестабильное ядро принимаются только исправления
ошибок (bugfix). Через некоторое время очередной версии присваивается
номер не a.b.c+1, а a.b+1.0 или a+1.0.0 - так появляется новая стабильная
серия, вокруг чего масс-медиа устраивают большую шумиху :) Еще через
некоторое время выпуск версий в предыдущей стабильной серии прекращается и
происходит т.н. fork или разветвление - одновременно с очередным стабильным
ядром появляется нестабильное, отличающееся от первого только номером версии.
Заметьте, что термины "стабильный" и "нестабильный" в чем-то условны.
Понятно, что "нестабильное" ядро 2.3.128 за несколько минут до его
превращения в стабильное ядро 2.4.0 по определению стабильно, а стабильное
ядро 2.2.xxx, в котором обнаружена фатальная ошибка распределения памяти --
опять же по определению нестабильно. В общем, сами понимать должны, не
маленькие.
В силу открытости процесса разработки ядра Linux существует несколько
побочных ветвей развития. Одной из основных таких ветвей являются ядра
серии -ac, которые выпускает Алан Кокс -- один из основных разработчиков
Линукса. Во-первых, серия -ac служит своеобразным буфером, в котором
тестируются некоторые новые драйвера, возможности, etc. перед тем, как
этот, уже оттестированный, драйвер будет отправлен Линусу. Во-вторых, в
ядрах -ac имеется определенный набор вещей, которые не устраивают Линуса,
но устраивают Алана и к тому же достаточно популярны.
Существуют также еще несколько менее важных (хотя ваше мнение по этому
вопросу может отличаться) побочных веток: например, International Kernel
Patch с поддержкой сильной криптографии, devfs-patch с поддержкой файловой
системы /dev, раньше была отдельная поддержка ISDN, ну и так далее и тому
подобное). Кроме того, многие производители дистрибутивов распространяют
ядро с определенными патчами, которые они считают необходимыми и которые
лучше вписываются в инфраструктуру дистрибутива).
Каким же ядром все-таки пользоваться? Простейший ответ: тем, которое
входит в используемый вами дистрибутив. Этот ответ приемлем для
большинства пользователей Линукса. Если же вы оказались в ситуации, когда,
например, нужное вам железо поддерживается только в каком-то патче, который
не вошел ни в одну из основных ветвей, значит, вам придется брать исходники
оригинального ядра, патчи, которые использовали создатели дистрибутива,
патчи, которые необходимы лично вам, прикладывать все эти патчи друг к
другу, компилировать и устанавливать ядро вручную (ну, или создать свой
собственный пакет на основе дистрибутивного). Вам также придется
отслеживать выход новых версий патча, контактировать с его автором,
сражаться с его глюками и прилагать всяческие усилия к тому, чтобы оный
патч, наконец, приобрел официальный статус.
Возможны и другие варианты, при которых может потребоваться пересборка,
наиболее очевидный - вы столкнулись с ошибкой в ядре, которая исправлена в
более свежей версии. В этом случае стоит сперва выяснить, не выложил ли
производитель вашего дистрибутива исправленное ядро на свой ftp сервер,
в то же место, где лежат прочие обновления. Такое ядро доступно в форме пакета
(rpm или deb), пригодного к непосредственной установке пакетным менеджером,
либо в дистрибутиве имеется система автоматического обновления пакетов.
Если же вам просто хочется поставить более свежую версию ядра или пересобрать
ядро без всякой причины ("убрать лишние драйвера", "изучить процесс сборки" и т.п.
причинами не считаются ;-), рекомендуется серьезно подумать, прежде чем
приступать к действиям. Не стоит чинить то, что не сломано. Объем трафика
ru.linux, посвященный проблемам при пересборке ядра весьма велик и не надо
еще больше его увеличивать :-). Однако обновления ядра от производителя
все-таки устанавливать рекомендуется в любом случае :-)
Итак, вы решили самостоятельно скомпилировать/установить ядро. Если оно
development - очень рекомендуется подписаться на список рассылки
linux-kernel. В любом случае желательно просматривать глазами патчи
перед установкой (особенно на предмет добавления новых опций и
изменений в каталоге Documentation). Еще крайне рекомендуется оставлять
старое ядро и делать в lilo отдельный target типа oldlinux, на него
показывающий. При смене стабильной серии на более новую стабильную надо
прочесть Documentation/Changes - как минимум. А лучше - все из этого
каталога, что относится к вашему железу и софту.
cd /usr/src/linux
Опции, с которыми компилируется ядро (тип процессора, драйверы
которые нужно включить (возможно в виде модулей) и еще сотни других вещей),
задаются в файле /usr/src/linux/.config. Так вот, желательно не создавать его
самому с нуля (особенно, если вы собираете ядро первый/второй/третий раз в
жизни или наложили патч на исходники из которых уже что-то компилировали),
а взять за основу .config с которым было собрано старое, работающее ядро.
При этом вам прежде всего надо выдать команду make oldconfig - она
используется, когда есть .config от _другой_ (обычно, более старой)
версии ядра, и нужно просто получить точно такой же для текущей
(возможно, ответив на пару вопросов о тех фичах, которых в старом не было),
не отвечая заново на все три сотни вопросов.
Затем выдайте make menuconfig и исправьте те опции, ради которых вы
собственно и решили пересобрать ядро.
Если вы используете Red Hat и хотите воспользоваться теми .config, c помощью
которых были собраны ядра в этом дистрибутиве, то возьмите их из
kernel-sources-*.i386.rpm/usr/src/linux/configs/
Затем:
make dep
make clean
make zImage (make bzImage для ядер версий > 2.2)
make modules
Если у вас раньше стояла эта же версия ядра, то удалите старые
модули от этого ядра (/lib/modules/версия).
make modules_install
/usr/src/linux/arch/i386/boot/(b)zImage - и есть свежесобранное ядро. Его
теперь можно поинсталировать на место старого. Хотя лучше сначала
попробовать, работает ли оно. Нужно добавить в lilo.conf еще один выбор -
например, linux.test, - который берет ядро прямо из
/usr/src/linux/arch/i386/boot/zImage.
(
Valentin Nechayev)
Я пpедлагаю дpугой метод - пpовеpен только для Red Hat'а.
cd /usr/src/linux-нужная_веpсия
vi Makefile и заменить extraversion на свой - напpимеp,
EXTRAVERSION = -vasya1
после этого все то же самое, но
- make modules_install поставится в свой отдельный каталог
- установка (пpавильная!) ядpа в /boot сделается сама чеpез make install
- это работает только с ядрами 2.2.x (у 2.0 просто нет параметра
EXTRAVERSION) и, по крайней мере теоретически, может "сломать" чей-нибудь
автоконфигуратор, рассчитывающий на n.n.nn по uname -r.
(Alexander Pevzner, 2:5020/59.9)
Тем, кто отважился на сборку ядра лично под себя, советуем обратить
внимание на следующие факты:
- В начале ядерного Makefile (/usr/src/linux/Makefile) есть переменная
EXTRAVERSION. Используя ее можно получать ядра одной и той же версии,
но с названиями, отличающимися суффиксом (напр, 2.2.12-20 и 2.2.12-vasya).
Это хорошо, поскольку позволяет сохранить экземпляр ядра, который
заведомо умеет грузиться. Родное ядро, с которым ставилась система,
лучше сохранить на случай всяких неприятностей. Hадо только не
забыть добавить дополнительную запись в /etc/lilo.conf (достаточно
иметь всего 2 записи: на родное ядро и на свежесобранное).
- В редхате в /usr/src/linux правильно работает make install и
make modules_install. Ядро и модули копируются в нужное место и
правильно настраиваются символические линки. Причем, что приятно,
это относится не только к ядрам, полученным в виде .src.rpm, но
и если просто взять ядро с ftp.kernel.org, все заработает.
(эту правильную установку осуществляет редхатовский скрипт /sbin/installkernel,
входящий в пакет с фирменным ядром редхата, поэтому перед make install
желательно убедиться в наличии этого скрипта (Alex Kanavin).)
EXTRAVERSION в этих ядрах по дефолту не выставлено, поэтому ядро
будет получаться под именем навроде 2.2.13 (конечно, EXTRAVERSION
при желании можно выставить)
- Когда ядро собирается в дереве, в котором уже собиралось ядро,
очень рекомендуется после make *config сказать make clean.
Во всяком случае, если какие-то части ядра были переселены в
модули или обратно, надо делать это _обязательно_, иначе есть
шанс собрать неправильное (не работающее) ядро.
В ядрах 2.2.10 и более новых:
echo 30000 > /proc/sys/fs/file-max
echo 30000 > /proc/sys/fs/inode-max
и сделать ulimit -n 2000 перед запуском нужного демона. Цифры
подбираются под задачу.
(Yuriy Kaminsky 2:5020/517.21)
И не забыть, что если программа использует select, то будет
большой-большой облом. Вплоть до затирания стека и падения (at least
glibc-2.0 - см. /usr/include/gnu/types.h - и иже с ним; исправления
#define __FD_SETSIZE 1024
на нужное число и пересборки всех приложений и библиотек , которые могут
заюзать select для дескрипторов выше 1024 будет достаточно [т.е.,
скажем, если X'овому приложению нужно открывать более 1024 файлов, то
необходимо пересобирать Xlib и Xt как минимум]; ах, да, саму libc
пересобирать, вроде, не нужно).
http://www.linuxdoc.org
Hа русском языке - посмотрите на
http://linux-ve.chat.ru
ftp://ftp.yggdrasil.com/private/hjl - если кому-то понадобилась
тухлятина. В
частности, именно там надо искать libc5 последних версий) Сейчас все это
лежит на
ftp://ftp.kernel.org/pub/linux/software/ и его
локальных миррорах. (
ftp://ftp.ru.kernel.org не миррорит
.bz2 (на 20% меньше gz, многое из каталога linux/kernel/people в .gz не
выкладывается), поэтому вместо
ftp://ftp.ru.kernel.org лучше пользоваться
ftp://ftp.rmt.ru или
http://ftp.filesearch.ru)
Очень коротко, подробнее можно прочесть в вышеназванных источниках:
ядро монтирует корневую файловую систему, и запускает первый процесс init,
разыскав его исполняемый файл в нескольких стандартных местах. Этот процесс
читает свой конфигурационный файл /etc/inittab (man inittab) и запускает
все остальные процессы согласно инструкциям из этого файла. Обычно в inittab
прописывается запуск процессов *getty, управляющих терминалами, виртуальными
консолями и последовательными линиями (то есть именно *getty ответственны за
запуск login (сравнивающий имя и пароль, указанные пользователем, с тем, что
прописано в /etc/passwd и в случае успеха запускающий соотв. shell),
pppd, ifcico и т.д., что именно запускается и в каком случае - зависит от
конкретного getty). Для виртуальных консолей обычно используется mingetty,
для модемов - mgetty.
Кроме того, здесь же прописываются скрипты, запускающиеся на различных т.н.
"уровнях выполнения", из которых в свою очередь запускаются все остальные
системные сервисы, осуществляется настройка сети, проверка файловой системы
и т.д. Существует два подхода к организации этих уровней и скриптов: BSD и
SysV. Оба они описаны в книжке Э. Немет (см. выше), а про SysV можно еще
прочесть на
http://www.sensi.org/~alec/unix/redhat/sysv-init.html.
Логи могут быть от syslog'а и от отдельных демонов.
syslog'овые логи чистятся так:
mv $log ${log}.old (или rm если не нужен, но лучше сохpанить)
touch $log
kill -1 `cat /var/run/syslogd.pid`
Процесс автоматизируется с помощью logrotate.
Как чистить не-syslog'овые логи - только RTFM на конкpетную тулзу и никак иначе.
http://www.kernel.org/pub/linux/libs/pam/
Надо ставить su не из gnu sh_util, которая в принципе этого
не умеет (RTFmanpage на предмет, по чьей милости), а какую-нибудь другую.
Но ежели su пользует pam (в Red Hat, напpимеp и основанных на нем
дистрибутивах, а также в Debian 2.2), подобное поведение достигается добавлением стpочки:
su auth required pam_wheel.so
в /etc/pam.conf, если pam дpевний, или:
auth required pam_wheel.so
в /etc/pam.d/su, если поновее.
Такой механизм получше будет, поскольку поведение можно ваpьиpовать на ходу.
Hапpимеp, манипулиpуя паpаметpами 'group' и 'deny', pазpешить это делать
всем, кpоме одной гpуппы:
pam_wheel.so group=guest deny
Пpавда, модуль этот стpанный, забывает смотpеть на gid, а смотpит
только на groups... А может так и надо...
В Debian 2.1 надо поставить пакетик secure-su и посмотреть на файл suauth.
В Slackware от 3.3 (гаpантиpовано) это pешается путем pедактиpования
/etc/login.defs Hужно, что бы было
SU_WHEEL_ONLY yes
тогда su смогут использовать только входящие в гpуппу root.
В слаквари от 3.4 (до 4.0, где su опять из другой банки) лучше
прочесть сперва man 5 suauth - там возможна гораздо более гибкая
настройка su, чем тупая "группа ноль".
Если память не вpет, то это же спpаведливо в SuSe 6.x. В SuSE 5.3 su из
sh_util, со всеми вытекающими. К сожалению, su, понимающая login.defs и
suauth, страдает другими болезнями - в частности, не имеет удобных
ключиков -m и -s. Если секьюрити важнее удобства...
man setrlimit
Во-первых, они должны использовать одно и то же имя файла для доступа к
порту, скажем, /dev/modem. Если одна программа использует /dev/ttyS0,
а другая /dev/cua0 (а третья -- /dev/modem, который линк на один из этих
двух :), - то они точно передерутся.
Во-вторых, они должны использовать механизм lock-файлов. Hаверное,
все известные программы его используют, но все же.
В-третьих, они должны видеть локи друг друга. То есть, в их
конфигурации должен быть указан один и тот же каталог для создания локов,
они должны использовать один и тот же формат имен файлов (обычно LCK..<имя
файла порта>), один и тот же формат самих файлов (обычно десять символов --
PID программы в ASCII), и иметь привилегии, достаточные для создания и
удаления своих лок-файлов.
Hе надо пользовать cua*. То есть вообще. Они в ядре - только для обратной
совместимости со схемой, принятой в BSD. В BSD /dev/cuXX --
это "Call Up" порты, т.е. для исходящих звонков -- на них всегда есть CD.
В Linux /dev/cuaXX не применяется и новые ядра даже выдают
предупреждение.
Для установки времени в CMOS используется утилита hwclock из свежего
комплекта util-linux.
Если на вашей машине стоит только Linux, то очень удобно записать в
CMOS время по Гринвичу, а в одном из стартовых скриптов сказать
/sbin/hwclock --hctosys --utc
Если на машине стоит, кроме Linux, какая-то другая операционная
система, то в CMOS пишется местное время, а в стартовом скрипте
пишется просто
/sbin/hwclock --hctosys
Для того, чтобы программы правильно определяли местное время (с учетом
летнего времени и тому подобных обстоятельств), надо:
В Red Hat-based системах параметр utc задается в файле /etc/sysconfig/clock.
Непосредственно редактировать стартовые скрипты не нужно. Кроме того,
этот параметр и timezone можно задать с помощью утилиты timeconfig.
Проверить правильность задания времени можно, запустив сначала
``date'' (должна показать правильное местное время), а затем ``date
--utc'' (должна показать правильное время по Гринвичу).
Для того, чтобы синхронизировать время с часовыми серверами в
Internet, сходите на
http://www.ntp.org. Там раздается пакет xntpd и
приведен список публично доступных часовых серверов в Интернете. Из
всего комплекта xntpd вам потребуется лишь программа ntpdate.
Периодически, например, при каждом звонке провайдеру, выполняйте,
например, такую команду:
/usr/local/bin/ntpdate ntp1.gamma.ru
Если на вашей машине под Linux установлена Samba, то клиенты под MS
Windows могут синхронизировать время с этой машиной с помощью команды
C:\> NET TIME \\LINUXBOX /SET /YES
(
Alexey Mahotkin)
port type pipe
port command /bin/telnet -8E hostname
Попробуйте fdmount /dev/fd[0-9] mountpoint, ну и не забыть почитать
man fdmount, или root мог написать 'user' в /etc/fstab, и обычный
пользователь может говорить "mount <mountpoint>". man 8 mount.
Еще лучше вовсе не монтировать дискеты, а пользоваться mtools.
Hадо заглянyть в директорию /var/log и посмотреть, нет ли в логах
сообщений от этой программы.
Для sendmail - 99% воплей пpо долгое думанье объясняется попыткой pезолвинга
адpесов локальных интеpфейсов. Hадо эти адpеса занести в /etc/hosts.
Альтеpнативный ваpиант - O DontProbeInterfaces=True в /etc/sendmail.cf.
Для начала прочтите /usr/doc/HOWTO/Security-HOWTO.
Hа
http://www.openwall.com можно найти патч Solar Designer-а,
который помогает от исполняемого стека и еще восьмидесяти восьми болезней.
Кроме того, рекомендуется придирчиво изучать
http://rootshell.com
http://packetstorm.securify.com,
http://www.linuxsecurity.com , и
подписаться на списки рассылки bugtraq, linux-security, и список по
безопасности того дистрибутива, которым вы пользуетесь.
Еще одна, хотя и несколько радикальная ссылка:
http://www.infowar.co.uk/thc/files/thc/anonymous-unix.html
- Если имеется ввиду перенос содержимого одной файловой системы
в другую, то одним из корректных способов сделать это будет
( cd /old_fs && tar cf - . ) | ( cd /new_fs && tar xvpf - )
- dump 0f - /old_fs | ( cd /new_fs && restore xf - )
и набирать побыстрее,
и понять легче, и кое-что, что у tar не получится или получится с трудом,
таким образом можно скопировать (атрибуты, файлы с "дырками"). Для tar
можно и попроще:
tar -C /old_fs -cf - . | tar -xpf - -C /new_fs
- GNU tar более интеллектуальная штука, чем dump.
- Подробное руководство есть в /usr/doc/HOWTO/mini/Hard-Disk-Upgrade
Sticky bit (chmod +t) на каталоге означает, что файлы в этом
каталоге могут стирать только их владельцы или суперпользователь.
Обычно на /tmp и /var/tmp этот бит включен.
Setgid бит (chmod +g) на каталоге означает, что файлы, созданные в
этом каталоге, будут иметь ту же группу-владельца, что и сам этот
каталог. Также, если в setgid-каталоге создаются другие каталоги, то
они также будут иметь setgid-бит.
По словам ДиДжея Бернстайна, "есть три метода задания групп-владельцев
файлов: BSD-шный, бесполезный и SVR4-й. При BSD-шном методе файлы всегда
получают ту же группу-владельца, что и каталог, в котором они были созданы.
Это очень удобно с точки зрения администратора.(*) При бесполезном методе
новые файлы принадлежат основной группе, на правах которой выполняется
текущий процесс. Этот случай моментально приводит к настоящему
кошмару. SVR4-й метод почти совпадает с бесполезным, но если на каталоге
есть setgid-бит, то включается BSD-шный метод."
Заметьте, что с помощью флага монтирования bsdgroups можно включить
BSD-шный метод работы с группами-владельцами. Подробности --
mount(8).
(*) Объяснение, почему удобно, можно найти в руководстве Red Hat -
rhref/s1-sysadmin-usr-grps.htm, Users, Groups and User-Private Groups)
Такое сообщение может появляться по нескольким причинам:
Прочтите man smrsh или /usr/share/doc/sendmail/README.smrsh
Next
Previous
Contents
