Как настроить Xendump в Red Hat Enterprise Linux 5?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-9864.pdf

Translated by Ivan Pesin, June 2009

Система: Red Hat Enterprise Linux 5

Решение:

Xendump это средство захвата дампов памяти гостевых систем Xen. Оно встроено в гипервизор Xen Hypervisor. Дампы памяти ядра полезны при выяснении причин краха системы. Для анализа таких дампов используется утилита crash. Утилита crash аналогична традиционной Unix-программе crash. Она предоставляет трассировки стека и другую отладочную функциональность для определения проблемных областей, вызывающих крах системы. Аналогичное средство, предназначенное для обычных (не-Xen) ядер, называется Kdump. Чтобы узнать больше о том, как работает Kdump, прочитайте Как настроить kexec/kdump в Red Hat Enterprise Linux 5? .

Чтобы настроить Xendump следуйте нижеприведённым инструкциям:

  1. Включите средство Xendump. Отредактируйте /etc/xen/xend-config.sxp и измените строку

    на:

  2. Перезапустите демон xen:

  3. Чтобы проверить работу Xendump, запустите гостевую систему Xen:

  4. Выполните захват памяти командой:

Обратите внимание, что на данный момент Xendump может быть настроен для автоматического захвата дампов памяти паравиртуальных (PV) гостевых систем Xen при их крахе. Для захвата дампа памяти гостевых систем Xen с полной виртуализацией (FV) Xen, необходимо выполнять команду xm dump-core вручную.

Как загрузить новое ядро с помощью kexec?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-9797.pdf.

Translated by Ivan Pesin, June 2009.

Система: Red Hat Enterprise Linux 5

Решение:

Kexec это механизм быстрой загрузки, который позволяет загружать ядро Linux из контекста уже запущенного ядра без передачи управления BIOS. Процедуры инициализации BIOS-а могут занимать очень много времени, особенно на больших серверах со множеством периферийных устройств. Механизм kexec позволяет сэкономить массу времени разработчикам, которые должны многократно перезагружать систему.

Проверьте, установлен ли пакет kexec-tools:

Следующие команды показывают, как можно подготовить к загрузке (загрузить) kernel-2.6.18-53.1.4.el5:

Чтобы передать управление подготовленному (загруженному) ядру, выполните:

Как настроить kexec/kdump в Red Hat Enterprise Linux 5?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-6039.pdf.

Translated by Ivan Pesin, June 2009.

Общее представление

Kexec это механизм быстрой загрузки, который позволяет загружать ядро Linux из контекста уже запущенного ядра без передачи управления BIOS. Процедуры инициализации BIOS-а могут занимать очень много времени, особенно на больших серверах со множеством периферийных устройств. Механизм kexec позволяет сэкономить массу времени разработчикам, которые должны многократно перезагружать систему.

Kdump это новый очень надёжный механизм получения дампа памяти при крахе ядра. Дамп захватывается в контексте свежезагруженного ядра, а не в контексте сбойного ядра. Kdump использует kexec чтобы загрузить второе ядро при сбое основного ядра. Это второе ядро, которое часто называют “ядром захвата” (capture kernel), загружается в небольшой участок памяти и создаёт образ памяти основного ядра.

Первое ядро резервирует часть памяти, которая используется вторым ядром при загрузке. Учтите, что kdump резервирует значительную часть памяти при загрузке, что меняет фактические минимальные требования к оперативной памяти Red Hat Enterprise Linux 5. Чтобы рассчитать их, обратитесь к документу http://www.redhat.com/rhel/details/limits/, где указаны минимальные требования к ОЗУ и прибавьте к ним количество памяти, необходимое для kdump.

Kexec реализует загрузку ядра захвата без передачи управления BIOS-у, а значит сохраняется содержимое памяти основного ядра, что и представляет собой дамп памяти ядра при крахе.

Установка Kdump

Проверьте, что пакет kexec-tools установлен:

Если он не установлен, установите его с помощью yum:

Расположение дампа Kdump

В файле /etc/kdump.conf должно быть указано место для сохранения дампа памяти ядра при крахе. Отсутствие этого параметра ведёт к неопределённому поведению Kdump. Есть возможность сохранять дамп непосредственно на устройство, в файл, или через сеть по протоколам NFS и SSH.

Дампирование на устройство

Вы можете настроить Kdump выполнять дамп непосредственно на устройство, указав директиву raw в файле kdump.conf. Синтаксис этой директивы такой:

Например:

Пожалуйста учтите, что эта конфигурация уничтожит все данные, которые находятся на этом устройстве.

Дампирование в файл на диске

Kdump может быть настроен монтировать раздел и сохранять дамп в файл на диске. Это делается указанием типа файловой системы и раздела в файле kdump.conf. Раздел может быть задан именем устройства, меткой файловой системы или UUID, аналогично тому, как это указывается в файле /etc/fstab.

По-умолчанию, каталог в котором будет сохранятся дамп, называется /var/crash/%DATE/, где %DATE — это текущая дата на момент создания дампа. Например, конфигурация:

смонтирует /dev/sda1, как устройство с файловой системой ext3, и запишет дамп в каталог /var/crash/, тогда как

смонтирует устройство с файловой системой ext3 и меткой /boot. На большинстве инсталляций Red Hat Enterprise Linux, это будет каталог /boot. Самый простой способ узнать, какое устройство нужно указать в конфигурации — посмотреть файл /etc/fstab. Как уже говорилось, каталог по-умолчанию для сохранения дампов называется /var/crash/%DATE/. Изменить его можно с помощью директивы path в файле kdump.conf. Например:

Эта конфигурация указывает, что сохранять файлы дампов нужно в каталоге /usr/local/cores/ вместо /var/crash/.

Дампирование на сетевое устройство по NFS

Чтобы настроить kdump для дампирования на том NFS, отредатируйте файл /etc/kdump.conf и добавьте в него строку в формате:

Например:

Эта директива указывает, что дамп памяти нужно сохранять в файл /export/vmcores/var/crash/[имя_хоста]-[дата] на сервере nfs.example.com. Система-клиент должна иметь права на запись для этого тома.

Дампирование на сетевое устройство по SSH

Преимущество SSH — шифрование передаваемого по сети трафика. По этой причине, этот метод является наилучшим в ситуации, когда дамп памяти нужно передавать через сеть с общем доступом, такую как Internet или корпоративную WAN.

Например:

В этом случае, kdump будет использовать scp для подключения к серверу crash.example.com под пользователем kdump. Дамп памяти будет скопирован в каталог /var/crash/[имя_хоста]-[дата]/. Пользователь kdump должен иметь необходимые права для записи на удалённом сервере.

Чтобы активировать внесённые в настройку изменения, выполните команду service kdump propagate, которая должна выдать примерно следующий вывод:

Задание выборки страниц и сжатие

На системах с большим объемом оперативной памяти рекомендуется не дампировать ненужные страницы памяти и сжимать остальные. Это настраивается в файле kdump.conf командой core_collector. На текущий момент единственным полностью поддерживаемым коллектором является makedumpfile. Его опции можно посмотреть командой makedumpfile --help. Опция -d указывает какие типы страниц не нужно дампировать. Параметр этой опции представляет битовую маску следующих типов:

Вообще говоря, все эти страницы не содержат ценной для отладки информации. Чтобы исключить их из дампа, укажите параметр -d 31. Опция -c говорит makedumpfile сжимать остальные страницы памяти.

Помните, что использование ключей -d и -c немного увеличивает время, необходимое для создания дампа памяти.

Добавление параметров загрузки

Необходимо модифицировать параметры загрузки основного ядра, чтобы зарезервировать память для ядра захвата. Для архитектур i386 и x86_64 отредактируйте файл /etc/grub.conf и добавьте crashkernel=128M@16M в конец строки с параметрами ядра.

Примечание: вы можете указать размер резервируемой памяти меньше 128M, но тестирование показало, что уже при 64M kdump может работать ненадёжно.

Пример файла /etc/grub.conf с добавленными параметрами kdump:

Тестирование

После внесения указанных изменений, перезагрузите систему. 128M памяти (начиная с 16M), зарезервированные для ядра захвата, не будут использоваться основной системой. Обратите внимание, что команда free -m покажет на 128M доступной памяти меньше, чем до настройки kdump.

Теперь, когда необходимая память выделена и зарезервирована, включите скрипт автозапуска kdump и запустите сервис:

В результате через kexec будет загружен образ ядра, что приготовит систему к захвату дампа памяти при крахе. Чтобы это проверить, вызовите крах системы с помощью sysrq:

Эта команда вызовет панику ядра, после чего система должна загрузить ядро kdump. Когда процесс загрузки дойдёт до момента запуска сервиса kdump, дамп памяти основного ядра будет скопирован на диск или другое место, указанное в файле /etc/kdump.conf.

Примечание: kdump не поддерживает работу консоли в режиме frame-buffers или X-ов. В системах, обычно работающих с параметром ядра вроде “vga=791” или с запущенным сервером X, изображение на консоли при загрузке ядра через kexec будет искажено. Тем не менее, это не помешает ядру kdump создать дамп памяти, а изображение восстановится после перезагрузки системы.

Как пользоваться списками контроля доступа (Access Controls Lists, ACLs) в Red Hat Enterprise Linux 5?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: kbase.redhat.com/faq/docs/DOC-9977.pdf

Translated by Ivan Pesin, June 2009

Списки контроля доступа (Access Control Lists, ACL) предоставляют дополнительные к традиционным правам возможности разграничения доступа к файлам и каталогам. Для того, чтобы использовать ACL, файловая система должна быть смонтирована с параметром acl:

Чтобы установить права доступа для для пользователя или группы, используйте команду setfacl -m.

Формат команды для установки пользовательского ACL:

Указанная команда даст пользователю ray права на чтение и выполнение файла /home/foo.txt.

Чтобы задать ACL для группы, используйте:

Команда в примере даёт группе accounting права на чтение, запись и выполнение файла /finance/foo.txt.

ACL по-умолчанию для каталога (этот ACL будет автоматически наследоваться любым файлом и каталогом, созданными в данном каталоге) устанавливается командой:

Эта команда указывает, что любой файл или каталог, созданный в каталоге brochures, будет автоматически доступен пользователю marketing на чтение, запись и выполнение.

Для удаления ACL используется команда:

Команда из примера убирает у пользователя ray права на чтение и выполнение файла /home/foo.txt.

Для того, чтобы узнать текущий ACL файла или каталога, используйте команду:

В результате выполнения этой команды выдаётся текущий ACL файла /home/foo.txt. Выглядит это приблизительно так:

За подробной информацией о списках контроля доступа обращайтесь к страницам руководства по командам setfacl и getfacl.

Как уменьшить время таймаута для смонтированного раздела NFS?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-6988.pdf

Translated by Ivan Pesin, June 2009

Если у вас смонтирован раздел с ненадёжного или медленного NFS-сервера, или вы просто не хотите ждать, вы можете изменить параметры монтирования такого раздела, уменьшив время таймаута. Кроме того, можно также отменить повторные попытки доступа после первого таймаута. Всё это можно сделать, задав опции timeo, retrans и intr для NFS-раздела в файле /etc/fstab. Ниже приведён пример такой записи:

  • Опция timeo задаёт время таймаута в десятых частях секунды, потому, если у вас медленная сеть, имеет смысл указать этот параметр побольше, например 3 или 4. Это позволит нормально работать в сетях с большими задержками.
  • Опция intr гарантирует, что процесс, выполняющий операции ввода/вывода на смонтированном NFS-томе, может быть прерван сигналами, если NFS-сервер будет недоступен. В частности, это позволяет использовать Ctrl+C и команду kill для прерывания процесса.
  • Опция retrans указывает количество повторных запросов к NFS-серверу, прежде чем определяется, что сервер недоступен.

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

Как запретить интерпретатору bash сохранять некоторые команды в истории команд?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-9477.pdf

Translated by Ivan Pesin, June 2009

Переменная окружения HISTCONTROL задаёт параметры сохранения команд в истории команд интерпретатора bash.

HISTCONTROL состоит из списка опций, разделённых двоеточием. Опции могут принимать следующие четыре значения:

  • Если список опций содержит ignorespace, то команды, начинающиеся с пробела, сохраняться в истории не будут.
  • Опция ignoredups указывает, что строки совпадающие с последней строкой истории, сохранятся не будут.
  • Опция ignoreboth — сокращение для ignorespace и ignoredups.
  • Опция erasedups говорит интерпретатору, что перед добавлением новой строки в историю команд, нужно удалить все старые строки, совпадающие с добавляемой.

Любое другое значение, кроме указанных, будет игнорироваться.

Если переменная HISTCONTROL не определена, или не содержит допустимого значения, все команды, вводимые в интерпретаторе, будут сохранены в истории команд.

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

Переменная HISTCONTROL может определяться и для конкретного пользователя, и на всю систему, аналогично всем другим переменным окружения интерпретатора bash. Например, чтобы задать опцию ignorespace для всей системы, добавьте следующую строку в файл /etc/bashrc:

export HISTCONTROL=ignorespace

Чтобы задать опцию для конкретного пользователя, укажите необходимую строку в файле .bash_profile в домашнем каталоге пользователя. Обратите внимание, что изменения не будут активизированы до тех пор, пока пользователь полностью не выйдет из интерпретатора и не зайдёт повторно.

Почему попытка удалённо выполнить команду sudo с помощью ssh оканчивается ошибкой?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-15839.pdf

Translated by Ivan Pesin, May 2009

Система: Red Hat Enterprise Linux 5

Проблема:

Попытка удалённого вызова команды sudo с помощью ssh заканчивается ошибкой.

Например:

$ ssh hostname sudo <command>
$ sudo: sorry, you must have a tty to run sudo

Решение:

Файл /etc/sudoers в Red Hat Enterprise Linux 5 по-умолчанию содержит флаг 'requiretty'. Когда этот флаг установлен, только зарегистрированные в системе пользователи могут выполнять команды с помощью sudo. Именно это и не позволяет выполнять удалённо команду sudo через rsh или ssh. Программы rsh и ssh не выделяют устройство псевдотерминала. Рекомендуется не убирать этот флаг, поскольку без псеводтерминала невозможно отключить эхо вводимых символов и, как следствие, отображение вводимого пароля.

Для принудительного выделения псевдотерминального устройства, укажите команде ssh параметр -t :

# ssh -t hostname sudo <cmd>

Как вариант, можно также отредактировать файл /etc/sudoers с помощью visudo и отключить флаг requiretty, закомментировав строку "Defaults: requiretty". Примечание: делать это не рекомендуется.

За подробной информацией обращайтесь к Red Hat Enterprise Linux Deployment Guide.

Как увеличить приоритет операций ввода-вывода некоторых процессов в Red Hat Enterprise Linux 5?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-16649.pdf

Translated by Ivan Pesin, May 2009

Система: Red Hat Enterprise Linux 5 и новее

Введение:
Приоритет и класс ввода/вывода процесса могут быть изменены командой ionice. Linux поддерживает три класса ввода/вывода:

  • Idle: процесс, имеющий класс idle, получает возможность работать с диском только если никакая другая программа не выполняет операций ввода/вывода в течении некоторого периода времени.
  • Best effort: этот класс используется всеми процессами по-умолчанию, если не был задан определённый класс ввода/вывода.
  • Real time: процессы, работающие в классе реального времени, получают доступ к диску в перую очередь, вне зависимости от того, что еще происходит в системе.

По-умолчанию, процессы работают в классе Best Effort с приоритетом равным нулю, т.е. с наивысшим приоритетом в этом классе. Наилучший вариант применения ionice — улучшение производительности в случаях, когда нужно одновременно выполнять два класса задач: такие, которые не требуют много ввода/вывода, но чувствительны к скорости выполнения операций, и такие, которые наоборот нетребовательны к скорости отклика, но выполняют много операций ввода/вывода.

Решение:
Для повышения приоритета ввода/вывода процесса используйте следующую команду:

# ionice -c1 -n0 -p<PID>

Где:

  • -c1 указывает класс реального времени
  • -n0 задаёт наивысший приоритет
  • -p <PID> указывает идентификатор процесса

Понизить приоритет ввода/вывода процесса можно командой:

# ionice -c2 -n4 -p<PID>

Где:

  • -c2 указывает класс best-effort
  • -n4 задаёт приоритет 4

Чтобы узнать текущий приоритет ввода/вывода процесса, выполните команду:

# ionice <PID>

Например:

# ionice 9709
realtime: prio 7

За подробной информацией о ключах команды ionice, обращайтесь к руководству, которое доступно по команде man ionice.

Применения
Если текущему командному интерпретатору задать класс idle, то все команды, которые из него вызываются, будут тоже выполняться в классе idle. Чтобы это сделать, нам понадобится переменная $$ интерпретаторов bash и sh.

Например:

# echo $$
29033

Этот вывод означает, что PID вашего текущего интерпретатора равен 29033. Если вы хотите назначить назначить ему класс idle, выполните команду:

# ionice -c3 -p$$

Теперь всё, что вы делаете в этом интерпретаторе, выполняется в классе idle.

Другим специальным применением ionice является приоритезация системных бекапов. Вы можете изменить приоритет ввода/вывода архивирующего программного обеспечения так, чтобы оно не мешало другим приложениям в системе.

Примечание: приоритеты и классы ввода/вывода поддерживаются начиная с версии ядра 2.6.13, при использовании планировщика ввода/вывода CFQ. В Red Hat Enterprise Linux 5 для того, чтобы узнать какой планировщик используется в данный момент, используйте команду cat /sys/block/[sh]d[a-z]*/queue/scheduler. Текущий планировщик будет выделен квадратными скобками..

Например, следующий вывод показывает, что сейчас используется планировщик CFQ:

$ cat /sys/block/[sh]d[a-z]*/queue/scheduler
noop anticipatory deadline [cfq]

Как в Red Hat Enterprise Linux 5 настроить мост для Xen на интерфейсе, отличном от eth0?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-10091.pdf

Translated by Ivan Pesin, May 2009

Система: Red Hat Enterprise Linux 5

Проблема:

Конфигурация Xen по-умолчанию автоматически включает в мост xenbr0 интерфейс eth0. Однако, в некоторых случаях бывает желательно включить в мост интерфейс, отличный от eth0, чтобы обеспечить гостевым системам доступ к другой сети.

Решение:

Для того, чтобы включить в мост xenbr0 интерфейс, отличный от eth0, необходимо передать дополнительный параметр скрипту network-bridge в файле /etc/xen/xend-config.sxp. Измените строку

(network-script network-bridge)

так, чтобы она включала имя интерфейса, который нужно включить в мост:

(network-script 'network-bridge netdev=eth1')

В этом примере, интерфейс eth1 будет включён в мост xenbr0. Если вы используете bonded-интерфейс, конфигурация будет выглядеть так:

(network-script 'network-bridge netdev=bond0')

При следующем старте демона xend для настройки моста будет использована новая конфигурация. Чтобы убедиться в правильности новой конфигурации, используйте команду brctl:

В этом примере, peth1 указан, как интерфейс входящий в мост xenbr0. Это означает, что интерфейс eth1 был корректно включён в мост.

Если необходимо, чтобы в мост входило несколько сетевых интерфейсов, например eth0 и eth1, прочитайте инструкции в совете Как объединить несколько сетевых интерфейсов Xen-хоста в мост, доступный гостевым системам?.

Где найти дополнительную информацию для отладки autofs?

Copyright (c) 2009 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (available at http://www.opencontent.org/openpub/).
Original article: http://kbase.redhat.com/faq/docs/DOC-1993.pdf

Translated by Ivan Pesin, May 2009

Использование ключа --debug системы automounter может помочь получить полезную информацию при отладке, но при этом генерируется большой объём журнальных записей. Поэтому, использование этого ключа рекомендуется лишь во время отладки конкретной проблемы.

Сначала настройте syslog писать сообщения уровня daemon.debug в отдельный файл. Это поможет в дальнейшем отбирать необходимые сообщения. Добавьте такую строку в файл /etc/syslog.conf:

daemon.debug /var/log/autofs

Перегрузите syslog:

service syslog reload

Разрешите режим отладки демона automount. В карте auto.master добавьте флаг --debug в нужной строке.

Например, у нас есть такая строка в файле auto.master:

/autofoo auto.foo --timeout=60

Измените её на следующую:

/autofoo auto.foo --timeout=60 --debug

Перегрузите autofs:

service autofs reload

В результате, autofs начнёт писать подробную информацию о своей работе в журнальный файл /var/log/autofs.

После того, как вы получили необходимую информацию, стоит отменить внесённые изменения. Удалите строки, добавленные в конфигурационные файлы, и перезапустите сервисы autofs и syslog.