Centos 6, как удалить старые ядра или немного про малоизвестные способности yum

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

Конечно, это легко найти в Google, но ведь мало просто решить проблему, интересно разобраться во всем этом :)

Так вот, некоторые пакетики при апдейтах могут поддерживать фичу "installonly", то есть пакет не удаляется, не заменяется, а просто устанавливается. Очевидно, при этом критически важные файлы такого пакета ни с чем конфликтовать не должны. По-умолчанию yum считает такими пакетами все, что может содержать ядра, и по-умолчанию в CentOS настроено сохранять 5 последних версий ядра.
Очевидно, связано это с потенциальными проблемами с новым ядром и необходимостью сохранять старые версии. Однако, в большинстве случаев, когда обновления делаются руками и потом делается перезагрузка, умолчательные 5 последних версий как-то слишком уж избыточно (а для случаев ежедневных апдейтов без перезагрузки - как-то слишком уж мало, ведь ядро, скажем, за год, может обновиться раз 10, последнее загруженное ядро уже давно затрется).
В таком случае идем в /etc/yum.conf и правим там installonly_limit на какое-то другое число, после чего будет заметен позитивный эффект на число одновременно установленных версий ядра.
Однако, иногда просто хочется удалить лишние ядра, ничего не меняя. Для этого в пакете yum-utils (yum install yum-utils) есть нехитрая утилита package-cleanup:

# package-cleanup --oldkernels --count=2

И останутся только 2 последних ядра.


После всего этого всем интересующимся рекомендуется почитать man 5 yum.conf, где есть множество интересных и [бес]полезных опций, например, ограничение используемой пропускной способности сети, сохранение пакетов на локальном диске после установки и т.п. Ну и ознакомиться с пакетом yum-utils поближе.

Про RCS для конфигурационных файлов

Уже не раз сталкивался с идеей сунуть конфиги на серверах в какую-то систему котроля версий. Систем этих, как известно, валом, на любой вкус. Но все популярные у программистов для такой задачи слабо подходят: отслеживают все дерево, что-то ломают и т.п. В то же время в самых древних скрижалях по администрированию UNIX можно встретить не менее древнюю систему контроля версий, с названием RCS - Revision Control System. Просто и очевидно.
После прочтения маленького мануала и прочих man rcsintro rcs ci co, и нескольких замученных в усмерть текстовых файлов, я родил такой вот враппер для текстового редактора, который можно легко впихнуть в .bashrc и пользоваться:

# RCS wrapper to help make all files versioned
vim() {
 if [ ! -e `dirname $1`/RCS ] ; then
  mkdir -v `dirname $1`/RCS
 fi
 if [ -e `dirname $1`/RCS/$1.v ] ; then
  co -l $1
  /usr/bin/vim $1
  ci -u $i
 else 
  ci -u $1
  co -l $1
  /usr/bin/vim $1
  ci -u $1
 fi
}

Он почти все делает сам, делая работу с версиями довольно-таки простой, но не лишен и недостатков. Так что если кто-то поднаторел с RCS, я бы хотел чтобы мы вместе это допилили до состояния предмета искусства.
Итак: если в директории файлы еще не подвергались работе с RCS - он создает каталог для хранения версий. Дело в том что в отсутсвие этого каталоге, файл с информацией об изменениях будет храниться тут же рядом, что не очень круто, и замусоривает каталог. Если каталог уже есть, но файл еще не подвергался пыткам - он вносится в систему контроля версий, затем вы его редактируете, и он заносит новую ревизию куда положено.

Итак, недостатки, а точнее один недостаток, который я совсем недавно обнаружил:
При редактировании файла с владельцем user:root и правами 600, владелец почему-то сбрасывается на root. Почему, пока не разобрался. Второе что, видимо, имеет те же корни - права на файл меняются так, чтобы он был только для чтения (из соображений "дабы никто не мог поправить файл в обход системы контроля версий). Обе эти вещи могут сделать файл конфигурации непригодным для использования приложением, так что тут надо как-то придумать хороший метод исправления проблемы.

Мы с Linux уже 7 лет :)

Только что осознал, что 7 лет назад купил на горбушке два двд с довольно-таки устаревшим на тот момент срезом Debian Sid и снес винду. И с тех пор вот как-то постоянно с Linux в контакте нахожусь. Не скажу, что это сильно отразилось на профессионализме, гг, ну да, я их админю, поддерживаю, иногда ковыряюсь глубоко внутри, много опыта, но все равно не оставляет чувство, что в нем еще огромное количество белых пятен, касающихся его применения в быту и на производстве, так сказать. Это оказало потрясающее влияние, надо сказать. Например, мне очень не хочется сталкиваться с чем-то другим, особенно Windows, потому что привычно и удобно работать все-таки в *nix системах. Нравится сама идеология и философия.
Linux сильно изменился за эти годы. XFree86 ушел, пришел Xorg, научился делать и определять почти все сам, и почти всегда делает это правильно. Появились KDE4, Gnome3, Unity, которые до сих пор не вписываются в старые привычки, PulseAudio и NetworkManager. Долгое время была привычка отрицать наличие этого всего, но постепенно понимаешь, что это все-таки прикольно, юзабельно и удобно. Появился Ubuntu, который я тоже яростно отрицал, пока не попробовал, и вот уже Debian отошел на второй план, а в IRC я узнал про много других интересных дистрибутивов. И не могу сказать что какой-то лучше другого (ну, есть такие, которые я презираю в принципе, потому что не вижу им применения), все они хороши для определенного круга задач. Так что не холиворьте, у всех свои вкусы и пожелания. Все растут, понимают больше и, я уверен, у всех ощущение что "дистрибутивов должно быть много" будет иметь место, особенно если Linux это не только OS для десктопа.
Ну и за эти 7 лет я таки прихожу к мнению что Linux готов для дескопа. Не среднестатистического, но готов. И Windows для этого же самого не среднестатистического десктопа не готов совсем. :)

Загрузка SeaTools for DOS с флешки

У Seagate есть фирменная утилита для тестирования жестких дисков и ремаппинга бед секторов. Распространяется она в виде .iso, так что подразумевается что вы будете загружать ее с CD. Но так уж вышло, что у меня вовсе отстутсвует такой девайс в десктопе (есть только пара IDE-приводов, а IDE-контроллера в материнке нету :)). Так что единственным выходом было как-то в Linux создать загрузочную флешку с этой программой. Как обычно, решение нашлось, и оно называется Syslinux.
Она входит в большинство дистрибутивов, так что ее просто нужно установить через пакетный менеджер. :) Далее, адаптируя для своего дистрибутива (пути к файлам syslinux могут отличаться), делаем примерно следующее:
1. Переразмечаем флешку, создавая только один раздел с типом fat, используя любимый редактор разделов (fdisk или что там у вас).
2. Делаем этот раздел активным (boot) с помощью того же редактора разделов (раздел в fdisk помечается звездочкой в колонке Boot, а флаг переключается командой "а").
3. Копируем на флешку загрузочный раздел syslinux:

# dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdb

(будьте внимательны и не копипастьте эту команду в консоль - здесь нужно указать правильное устройство :))
4. Теперь устанавливаем syslinux в этот единственный раздел на флешке:

# syslinux /dev/sdb1

5. Теперь флешку можно смонтировать:

# mkdir /media/SEATOOLS ; mount -t vfat /dev/sdb1 /media/SEATOOLS

6. Для загрузки ISO нам потребуется memdisk из комплекта syslinux:

# cp /usr/lib/syslinux/memdisk /media/SEATOOLS

7. Теперь скопируем образ SeaTools на флешку.
8. В финале в корне флешки создается конфигурационный файл syslinux.cfg с примерно таким содержанием:

DEFAULT SeaTools
LABEL SeaTools
LINUX memdisk
INITRD SeaToolsDOS220EURO.144.ISO
APPEND iso

Стоит заметить, что такое прокатывает со множеством небольших iso-образов, если они вмещаются в память компьютера. Но дистрибутивы линукса прямо вот так работать не будут, потому что полученный виртуальный диск с содержимым .iso - не CD-ROM, и для этого нужно использовать специальные рецепты или утилиту unetbootin

Про эти надоедливые локализации

У меня есть только одна позиция насчет иных локализаций интерфейсов, кроме английской, и я теперь ее намерен озвучить.
Начну с главного - нет ничего плохого для простых пользователей в том что они видят систему и приложения на родном, не английском, языке. Это славно и нужно. Но подчастую эта локализация настолько потрясает своим качеством исполнения, что на несколько секунд накатывает желание покалечить, или даже убить того кто их делает. Может тогда не стоит локализовать приложения совсем? Пользователи хотя-бы чуть-чуть станут полиглотами :).
Итак, проблемы по пунктам:
1. Орфография. В свое время я репортил проблемы с локализацией KeePassX, в которой были допущены вопиющие орфографические ошибки типа слова "пороли". Я так полагаю, что авторы явно не проверяют локализацию, как и майнтейнеры пакетов, которые, возможно, включают это вне зависимости от апстрима. В любом случае, баги поправили. Вот только не помню кто - я сам пошел и поправил или эти ребята таки меня услышали. В багрепорт ответили где можно это исправить.
2. Искажение смысла. Конкретного примера не приведу уже, не помню, но думаю, что все встречали какой-то такой странный перевод, что догадаться что кокретная функция делает именно то что нужно было нереально. (Хотя вот вы все думаете что "Пуск" в Windows это очевидный перевод. На самом деле я еще помню людей, которые впервые видели Windows 98, тыкали иконку на рабочем столе и пытались запусть ее кнопкой "Пуск". Ведь тогда подсказки, пролетающей по таскбару, с текстом "Нажмите тут чтобы начать работу" уже не было.)
3. Локализация добавляет эпичный баг, который делает софт неюзабельным. Вот пример, который я репортил, и который был куда-то подвинут в сторну прогресса только спустя годы: https://bugs.launchpad.net/ubuntu/+source/gtypist/+bug/281946. Т.е. локализаторы, судя по всему, не смотрят что случилось с приложением после локализации.
4. Просто убийственно - если какой-то системный инструмент после буквального перевода всем понятных терминов с английского языка вызывает громкий смех. Например, в какой-то версии 9.х Ubuntu кто-то решил локализовать вывод ifconfig и iproute2. Все получили чудесное "ВВЕРХ BROADCAST RUNNING MULTICAST" вместо "UP BROADCAST..." и "Диапазон: ссылка" вместо "Scope:Link". Но это скорее к пункту 2, наверное.
5. Иметь счастье искать по локализованному сообщению по ошибке решение проблемы в поисковиках почти не имеет смысла.
6. Иногда вы имеете сообщение об ошибке в консоли в неправильной кодировке и даже не можете его разобрать. Например, когда соединились с сервером с архаичной локалью в koi8-r с современного десктопа с UTF-8. Да, это решаемо, но лишними движениями. Оно мне надо?
7. Недавно на Хабре увидел скрины локализованного Netbeans. Сразу возникла мысль "И что, это правда можно вот так пользовать?". Смотрите сами: "Refactoring" заменено на "Реорганизация кода", хотя "рефакторинг" 99% программистам уже давно известное слово. "Участок текста" вместо "Text field". Это вообще искажение смысла. "Поле ввода" было бы куда понятнее, не так ли? Я уж не говорю что JTextField куда проще связать с Text Field нежели с "Участок текста". Т.е. названия компонентов в оригинале намного проще связать с классами компонентов. (Чорт, может им стоило еще и классы и синтаксис Java локализовать? А что, язык это позволяет...). Продолжаем глумиться - "Версии API-интерфеса". Версии МСМасла-Масла - Мягкого Сливочного Масла-Масла. "Построить" вместо "Build" не умиляет?

От себя добавлю, что я использую английскую локализацию где только можно. Потому что надоели.

CFLAGS, CXXFLAGS и стоит ли так увлекаться их изменением?

Пользуясь случаем, даю ссылку на свой топик на WeLinux
В нем я немножко травлю тех пользователей (не всех!) Gentoo или Funtoo, которые бездумно меняют флаги компиляторов, ничего не тестируя и не сравнивая и потом пишут, что:  "Собрання под мой процессор система в стопицот раз круче чем любая другая! Я вот собираю с этими (20 флагов) и весь софт летает!".

Вы легко можете узнать их - обычно на вопрос "а где бенчмарк?" они ответят какую-то неконструктивную гадость вроде "я чоли твой персональный тестер?".

Почему я начал? Да просто вот на примере FireFox5, описанном в топике, очевидно, что компилятор влияет, иногда аж на 20%, на производительность софта. Возможно, есть софт, который выигрывает (или проигрывает) даже сильнее. Поэтому интересно узнать, кто еще что тестировал и чего добился. Интересует любой действительно важный для пользователя софт (Например, браузер, офисный пакет или что еще в таком духе), либо демон/сервис, для которого производительность реально важна - это например, SQL БД, http-сервер или, скажем, proxy, mail и что угодно еще, что удалось разогнать на 20 и более %.

Про реагирование на OutOfMemoryException в Java

Есть такая неприятная ситуация, когда память в куче заканчивается, и сборщик мусора тратит все больше и больше времени, пытаясь ее безрезультатно освободить, потому что объекты еще используется. Когда на это тратится почти 100% процессорноного времени, JVM может внезапно выбросить OutOfMemoryException в треде, который попытался выделить еще память. Как правило, это означает полную смерть треда, а может и всего приложения. Что еще неприятнее, отловить эту ситуацию изнутри практически нереально.
Но, как оказалось, можно хотя-бы сообщить об этом наружу, что можно использовать чтобы послать, скажем, письмецо с сервера о том что сервис помер, или даже убить и перезапустить его.

Делается это опцией для JVM:
java ... -XX:OnOutOfMemoryError="shell command; ..."

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