Tips & tricks

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2005 by Red Hat, Inc.

Original article: http://www.redhat.com/magazine/021jul06/departments/tips_tricks/

Red Hat Magazine, выпуск 21, июль 2006

Перевод: © Иван Песин

Служба поддержки пользователей Red Hat получает технические вопросы со всего мира. Специалисты Red Hat ежедневно добавляют полученные вопросы и ответы на них в базу знаний Red Hat Knowledgebase. Доступ к ней свободен для всех. Каждый месяц Red Hat Magazine знакомит читателей с Red Hat Knowledgebase, публикуя несколько самых свежих вопросов и ответов.

Советы от RHCE

Совместное использование устройства горячего резерва в программном RAID

Задумывались ли вы когда-нибудь над возможностью совместного использования устройства горячего резерва двумя 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 в Mozilla Firefox?

Ниже описывается последовательность действий, необходимая для активации технологии конвейеризации HTTP V1.1, которая по-умолчанию запрещена. Поскольку большинство веб-серверов сегодня поддерживает соединения по протоколу версии 1.1, а применение конвейеризации согласовывается, использование данной технологии не должно повлечь за собой какие-либо проблемы. Обратите внимание, что мы не меняем максимальное количество параллельных соединений (которое равно стандарту де-факто -- 4), а просто разрешаем возможность их сохранения для выполнения дальнейших запросов. В противном случае, при каждом запросе, каждое соединение создается и разрушается.

  1. Набирите в адресной строке "about:config" и нажмите return. Найдите следующие параметры:
    • network.http.pipelining
    • network.http.proxy.pipelining
    • network.http.pipelining.maxrequests
  2. Измените их:
    • Установите "network.http.pipelining" равным "true"
    • Установите "network.http.proxy.pipelining" равным "true"
    • Установите "network.http.pipelining.maxrequests" равным приблизительно 30. Это означает, выполнять сразу до 30 запросов.
  3. Наконец, нажмите правую кнопку мыши и выберите New-> Integer. Назовите параметр "nglayout.initialpaint.delay" и установите его значение в "0". Это значение задает время задержки перед началом прорисовки страницы.

Как можно контролировать arp-ответы для LVS?

В 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, выполните следующие действия:

  1. Проверьте целостность архива bzip2 командой:
    bzip2 -t [имя_файла]
  2. Если файл поврежден, выполните:
    bzip2recover [имя_файла]
  3. Наконец, дайте команду:
    bzip2 -dc rec*file.bz2 > [восстановленные_данные]

Как можно задать сообщение, выдаваемое при входе в систему менеджером gdm, в Red Hat Enterprise Linux 3?

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

Ограничение: Данная статья применима только к рабочему столу Gnome.

Решение:

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

  1. Создайте резервную копию файла /etc/X11/gdm/PreSession/Default:
    cp /etc/X11/gdm/PreSession/Default /etc/X11/gdm/PreSession/Default.orig
  2. Отредактируйте файл с помощью текстового редактора:
    vi /etc/X11/gdm/PreSession/Default
  3. Добавьте приведенные ниже команды после директивы PATH:
    # 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
  4. Чтобы проверить изменения, выйдите и зайдите в систему. При регистрации должно появиться окно с сообщением.

За подробной информацией о программе gdialog, обратитесь к странице руководства:

man gdialog

Как настроить Red Hat Enterprise Linux в качестве маршрутизатора, выполняющего преобразование адресов (NAT) с помощью iptables?

Ограничения:
Применимо к 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

Может ли 64-битный x86-64 GDB генерировать корректные 32-битные дампы памяти с помощью gcore из Red Hat Enterprise Linux 4 Update 3?

Нет. Поставляемый с дистрибутивом (Red Hat Enterprise Linux 4 Update 3) rpm-пакет с 64-битным x86-64 GDB на данный момент не может создавать корректные дампы памяти 32-битных приложений с помощью команды GDB gcore. Тем не менее, он может считывать 32-битные дампы памяти.

Примечание: Рассматриваются варианты устранения данного органичения в следующем обновлении Red Hat Enterprise Linux 4.

Как можно изменить время бездействия по-умолчанию для autofs?

Время бездействия по-умолчанию для autofs равно 300 секундам (5 минутам). После пяти минут бездействия, смонтированная файловая система будет автоматически размонтирована. Это типичное и безопасное значение. Если его нужно изменить, то новое значение можно указать в файле /etc/auto.master. Значение задается в секундах.

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

/misc /etc/auto.misc --timeout=60

Установка опции --timeout равной 0 полностью запрещает размонтирование.

Внимание: В некоторых ситуациях, запрет автоматического размонтирования, может иметь отрицательные побочные эффекты. Принимайте во внимание доступные сетевые ресурсы и объем свободной оперативной памяти.

Как восстановить работу панели GNOME в Red Hat Enterprise Linux 4, если после сворачивания приложений перестает отображаться селектор окон ?

Система: 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

Ждем отзывов об этом совете. Проблема возникает эпизодично, а данный совет был опробован на нескольких тестовых системах.