Original article: http://www.redhat.com/magazine/021jul06/departments/tips_tricks/
Перевод: © Иван Песин
Служба поддержки пользователей Red Hat получает технические вопросы со всего мира. Специалисты Red Hat ежедневно добавляют полученные вопросы и ответы на них в базу знаний Red Hat Knowledgebase. Доступ к ней свободен для всех. Каждый месяц Red Hat Magazine знакомит читателей с Red Hat Knowledgebase, публикуя несколько самых свежих вопросов и ответов.
Задумывались ли вы когда-нибудь над возможностью совместного использования устройства горячего резерва двумя RAID-массивами? Вы можете реализовать такую схему, если запустить mdadm в режиме демона и настроить опрос ваших RAID-массивов.
Давайте представим, что у нас есть два RAID-массива уровня 1 с одним устройством горячего резерва, настроенные следующим образом:
/dev/md0 RAID1
--
/dev/sda1
/dev/sdb1
/dev/md1 RAID1
--
/dev/sdc1
/dev/sdd1
/dev/sde1 (устройство горячего резерва)
Как видно, имеется массив /dev/md0, состоящий из двух устройств, и массив /dev/md1, состоящий из трех, причем /dev/sde1 является устройством горячего резерва. Таким образом, мы хотим использовать, если возникнет необходимость, устройство /dev/sde1 и для массива /dev/md0. Для этого, мы должны создать конфигурационный файл /etc/mdadm.conf и определить имя группы резерва.
Начнем с перечисления всех устройств в файле /etc/mdadm.conf:
echo "DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1"
>> /etc/mdadm.conf
Запросим RAID-массивы об их параметрах и добавим эту информацию в файл:
mdadm -D -s >> /etc/mdadm.conf
Теперь файл /etc/mdadm.conf должен содержать примерно следующую информацию:
# Caution, the ARRAY and UUID should be on the same line.
DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=29bc861f:6f1c72b0:162f7a88:1db03ffe
devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=aee2ae4c:ec7e4bab:51aefe40:9b54af78
devices=/dev/sdc1,/dev/sdd1,/dev/sde1
На данном этапе, нам нужно определить группу резерва для каждого массива. Имя не имеет значения, важно чтобы оно было одинаковым для всех массивов, которые должны совместно использовать устройства горячего резерва.
Здесь мы назвали группу резерва "shared" и добавили ее определения к каждому массиву в файле /etc/mdadm.conf:
# Caution, the ARRAY and UUID should be on the same line.
DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=29bc861f:6f1c72b0:162f7a88:1db03ffe
devices=/dev/sda1,/dev/sdb1
spare-group=shared
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=aee2ae4c:ec7e4bab:51aefe40:9b54af78
devices=/dev/sdc1,/dev/sdd1,/dev/sde1
spare-group=shared
Закончив с настройкой, можно запускать mdadm в режиме демона для опроса массивов. Если mdadm определит, что какое-либо устройство вышло из строя, то попытается найти, в той же группе резерва, массив с устройством горячего резерва. Если такой массив существует, mdadm переносит устройство горячего резерва в массив, которому оно необходимо. В нашем случае, если /dev/md0 потеряет устройства, mdadm найдет массив /dev/md1, в котором есть два штатных устройства и одно горячего резерва. Устройство горячего резерва будет перенесено в /dev/md0, после чего запустится процесс восстановления.
Запустите mdadm в режиме демона для мониторинга массивов:
mdadm -F -s -m root@localhost -f
Интервал между опросами по-умолчанию равен 60 секундам, но может быть изменен с помощью опции -d (т.е. -d 300 установит интервал равным 5 минутам).
Проверим нашу конфигурацию, убрав устройство из массива /dev/md0:
mdadm /dev/md0 -f /dev/sda1 -r /dev/sda1
При следующем опросе, mdadm должен определить, что /dev/md1 имеет устройство горячего резерва, перенести /dev/sde1 в массив /dev/md0 и запустить процесс его восстановления. После этого, вы можете добавить /dev/sda1 и оно станет вашим устройством горячего резерва:
mdadm /dev/md0 -a /dev/sda1
Ниже описывается последовательность действий, необходимая для активации технологии конвейеризации HTTP V1.1, которая по-умолчанию запрещена. Поскольку большинство веб-серверов сегодня поддерживает соединения по протоколу версии 1.1, а применение конвейеризации согласовывается, использование данной технологии не должно повлечь за собой какие-либо проблемы. Обратите внимание, что мы не меняем максимальное количество параллельных соединений (которое равно стандарту де-факто -- 4), а просто разрешаем возможность их сохранения для выполнения дальнейших запросов. В противном случае, при каждом запросе, каждое соединение создается и разрушается.
В Red Hat® Enterprise Linux® 4 управлять arp-ответами на разных интерфейсах можно с помощью параметров, задаваемых в файле /etc/sysctl.conf. Они могут принимать следующие значения:
arp_ignore - INTEGER
Задает режимы отсылки ответов на полученные ARP-запросы,
относящиеся к локальным IP-адресам:
0 - (по-умолчанию): отвечать на запросы о любом локальном
IP-адресе, сконфигурированном на любом интерфейсе
1 - отвечать только в том случае, если интересующий IP-адрес
является локальным на интерфейсе, получившем запрос
2 - отвечать только в том случае, если интересующий IP-адрес
является локальным на интерфейсе, получившем запрос, и находится
в той же подсети, из которой поступил запрос
3 - отвечать только на запросы для глобальных и канальных адресов
4-7 - зарезервированы
8 - не отвечать ни для каких локальных адресов
При получения ARP-запроса на {интерфейсе} используется большее
значение из conf/{all,интерфейс}/arp_ignore
arp_announce - INTEGER
Задает уровень ограничений при анонсировании локальных
IP-адресов на интерфейсе:
0 - (по-умолчанию) использовать любой локальных IP-адрес,
сконфигурированный на данном интерфейсе
1 - пытаться избегать передачи локального адреса, который
не относится к подсети получателя. Этот режим полезен в тех
случаях, когда адресат, доступный через данный интерфейс,
в ARP-запросе требует, чтобы IP-адрес отправителя находился
в той же подсети, что и он сам. При генерации ответа
проверяются все подсети, включающие IP-адрес получателя, и
выбирается в качестве исходящего адрес в одной из таких
подсетей, если таковые есть. Если же их нет, исходящий
адрес выбирается в соответствии с правилами уровня 2.
2 - всегда использовать лучший из локальных адресов для
данного получателя. В этом режиме адрес источника в IP-пакете
игнорируется и принимается попытка выбрать локальный адрес,
наиболее предпочтительный для общения с целевым хостом.
Такой адрес выбирается путем просмотра первичных IP-адресов
всех сетей на исходящих интерфейсах в поисках адреса, входящего
в подсеть получателя. Если подходящий адрес не найден,
выбирается первый локальный адрес исходящего или прочих
интерфейсов, в надежде на получение ответа на запрос,
иногда даже не зависимо от анонсируемого IP-адреса.
Используется большее значение из conf/{all,interface}/arp_announce.
Увеличение уровня ограничений повышает шансы на получение
ответа, тогда как уменьшение позволяет анонсировать более
достоверную информацию.
Типичная настройка LVS выглядит следующим образом:
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
Чтобы восстановить поврежденный архив bzip2, выполните следующие действия:
bzip2 -t [имя_файла]
bzip2recover [имя_файла]
bzip2 -dc rec*file.bz2 > [восстановленные_данные]
Система: Red Hat Enterprise Linux 3
Ограничение: Данная статья применима только к рабочему столу Gnome.
Решение:
У компаний и государственных организаций часто возникает необходимость выдавать информационное сообщение при регистрации в системе. Чтобы реализовать окно с таким сообщением на 5-м уровне выполнения системы (графический режим), выполните следующие шаги:
cp /etc/X11/gdm/PreSession/Default /etc/X11/gdm/PreSession/Default.orig
vi /etc/X11/gdm/PreSession/Default
# Login banner
/usr/bin/gdialog --yesno "Standard Disclaimer Text"
if ( test 1 -eq $? );then
# To avoid staring at a blank screen for next 10 second,
# and to miss the date with xsession-error dialog
gdialog --infobox "Loggin Out in 10secs" 1 20 &
sleep 10
exit 1
fi
За подробной информацией о программе gdialog, обратитесь к странице руководства:
man gdialog
Ограничения:
Применимо к Red Hat Enterprise Linux 3 и выше.
Есть несколько способов настройки Linux-машины в качестве маршрутизатора. Ниже описан относительно простой и стандартный метод. Он требует использования iptables для трансляции сетевых адресов (Network Address Translation, NAT).
Разрешить продвижение пактов:
echo "1" > /proc/sys/net/ipv4/ip_forward
Чтобы сделать данную настройку постоянной, укажите net.ipv4.ip_forward = 1 в файле /etc/sysctl.conf. Например:
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
Далее, передайте трансляцию сетевых адресов iptables:
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
где eth0 это интерфейс "внешнего" подключения. Нужно, также, задать ограничивающий набор правил iptables. Не забудьте сохранить настройки iptables командой:
service iptables save
Обратитесь к другим статьям из базы знаний за информацией и советами по настройке iptables.
Чтобы посмотреть таблицу маршрутизации, введите:
netstat -rn
Чтобы посмотреть набор правил, выполните:
iptables -L
Нет. Поставляемый с дистрибутивом (Red Hat Enterprise Linux 4 Update 3) rpm-пакет с 64-битным x86-64 GDB на данный момент не может создавать корректные дампы памяти 32-битных приложений с помощью команды GDB gcore. Тем не менее, он может считывать 32-битные дампы памяти.
Примечание: Рассматриваются варианты устранения данного органичения в следующем обновлении Red Hat Enterprise Linux 4.
Время бездействия по-умолчанию для autofs равно 300 секундам (5 минутам). После пяти минут бездействия, смонтированная файловая система будет автоматически размонтирована. Это типичное и безопасное значение. Если его нужно изменить, то новое значение можно указать в файле /etc/auto.master. Значение задается в секундах.
Например, следующая строка указывает на необходимость размонтирования после 60 секунд бездействия:
/misc /etc/auto.misc --timeout=60
Установка опции --timeout равной 0 полностью запрещает размонтирование.
Внимание: В некоторых ситуациях, запрет автоматического размонтирования, может иметь отрицательные побочные эффекты. Принимайте во внимание доступные сетевые ресурсы и объем свободной оперативной памяти.
Система: Red Hat Enterprise Linux 4
Проблема:
После полной загрузки системы при регистрации пользователя в системе, на экран выводится следующее сообщение:
The "Windows List" applets appears to have died unexpectedly.
Do you want to reload this applet?
If you choose not to reload it at this time you can always add it by
right clicking on the panel and clicking the "Add to Panel" submenu.
No Yes
Если вы нажмете "Yes", апплет будет перезагружен, а панель будет работать нормально. Выбор "No" нарушает работу панели и при сворачивании приложений с неё исчезает селектор окон.
Решение:
Если панель была удалена с рабочего стола, кликните правой кнопкой мыши на существующей (главной) панели и выберите "New
Panel". Должна появиться пустая панель. Теперь, кликните правой кнопкой мыши на новой панели и выберите "Add
to Panel..."
Появится селектор Add to the Panel. Выберите из него "Window Selector, Switch between open windows". Нажмите кнопку Add. Это должно решить данную проблему.
Совет: во избежание повторения этой ошибки при следующих входах в систему, попробуйте удалить файл .gnome2/session из домашнего каталога пользователя. Этот файл будет создан при следующем запуске GNOME. Однако перед удалением рекомендуется сделать резервную копию этого файла:
cp .gnome2/session .gnome2/session.bak
rm .gnome2/session
Ждем отзывов об этом совете. Проблема возникает эпизодично, а данный совет был опробован на нескольких тестовых системах.