Reboot the switch.

[security]
DisallowTCP=false

Файл нужен для переопределения дефолтных настроек, которые хранятся в /usr/share/gdm/gdm.schemas.

После изменения настроек в custom.conf можно перезапустить gdm командой service gdm restart

Для версии 11.10:
Здесь опять все перепилили. GDMа теперь нет. Есть LightDM. Включить сеть для иксов так:
1) открыть файл /etc/lightdm/lightdm.conf
2)в секцию [SeatDefaults] добавить строку:
xserver-allow-tcp=true
3) создать еще одну секцию:
[XDMCPServer]
enabled=true


Перезапустить менеджер:
sudo restart lightdm

Проблема заключается в том, что после успешного бэкапа в датапротекторе сессия закрывается со статусом competed, но на клиенте процесс omnib продолжает висеть, ожидая команд от сел мэнеджера. А команды не приходят, поскольку файрвол оборвал TCP сессию по порту 5555 между сел менеджером и клиентом по таймауту. После установки миллиона патчей решение было найдено буквально под ногами. Нужно было включить KeepAlive!

Что нужно для включения KeepAlive:
1) Tru64 Unix:
sysconfig -r inet tcp_keepalive_default=1
2) HP-UX:
ndd -set /dev/tcp tcp_keepalive_interval 900000
3) DataProtector:
На всех участниках бэкапа в .omnirc добавить строку OB2IPCKEEPALIVE=1

После включения кипэлайвов сессии перестали обрываться и бэкап работает как часы :)

Сбросить состояние всех «Poor» лент библиотеки:
for f in `omnirpt -report media_list | grep LIBNAME: | grep Poor | awk '{print $2}'`; do omnimm -reset_poor_medium $f; done

Есть задача скопировать базу данных с хоста fox.company.org на хост wolf.company.org. К каждому хосту через SAN подключены 4-е драйва ленточной библиотеки. Т.е каждый из хостов может оперировать ими как локальными. На каждом хосте установлен DataProtector MediaAgent, DiskAgent, Oracle Integration. Оба хоста входят в селл dp-cm.company.org.

Если запустить Full Backup оракла на хосте fox.company,org и попытаться его восстановить на хосте wolf.company.org не меняя настроек, то DataProtector будет использовать те же драйвы и через те же пути, которые использовались для бэкапа. Т.е. MediaAgent на хосте fox.company.org будет читать данные с локального SAN-attached драйва и копировать их по IP сети на хост wolf.company.org. Такая схема работы не всегда приемлима, поскольку создает дополнительную нагрузку на сеть и на хост fox.company.org.

Чтобы избежать подобной схемы работы DataProtector я применяю следующий метод. После прохождения Full Backup’а я отключаю опцию «MultiPath Device» в свойствах драйва через интерфейс датапротектора (Devices & Media -> MSL -> Drives -> msl_drive1 -> Properties -> MultiPath Device) и указываю хост, через который подключен драйв «wolf.company.org». Таким образом с точки зрения DataProtector первый драйв будет связан только с одним хостом и будет использоваться только один MediaAgent на хосте wolf.company.org.

Далее нужно подправить базу данных DataProtector и подменить драйвы, которые использовались для бэкапа. Для этого нужно воспользоваться командами omnirpt и omnidbutil.
Сначала делаем выборку сессий, которые состоялись во время FullBackup’a базы данных:
omnirpt -report list_sessions -timeframe 48 48 -datalist "Oracle8 oraback" -tab | grep -v "^#" |awk '{print $26}' > /tmp/session_list
В данном случае будет сделана выборка сессий за последние 48 часов по бэкап спецификации Oracle8 oraback. Полученный список будет сохранен в файл /tmp/session_list.

Теперь нужно обработать каждую сессию:
for f in `cat /tmp/session_list`; do omnidbutil -changebdev msl_drive2 msl_drive1 -session $f; done
Если для бэкапа использовался не только драйв msl_drive2, то нужно повторить процедуру для каждого драйва. После этих манипуляций в базе DataProtector’а не останется упоминаний о том, что бэкап проходил по каким-либо драйвам кроме msl_drive1. А этот драйв я уже сконфигурировал таким образом, что единственным путем для него будет хост wolf.company.org.

Запускаем восстановление базы данных. После окончания восстановления не забываем включить MultiPath Device в свойствах драйва в DataProtector’е

Вот работаю я в одной крупной конторе. Рулю не менее крупным оборудованием. И все в этом оборудовании прекрасно – и внешний вид, и внутренняя идеология, и программы, с помощью которых этим оборудованием можно управлять, и обучение по этому оборудованию.

Привозят, скажем, новый сервер, новый дисковый массив, новый FC коммутатор. Собираем это все вместе, включаем и, о чудо! Оно работает. Устанавливаем туда свои программы, пользуемся ими. И тут, вдруг, происходит нечто. Что-то такое, чего вполне можно было ожидать и все готовы к такому происшествию. Тема выхода из строя обсуждалась при планировании, при закупке, во время обучения. Есть документация, есть умные программы. Есть все, чтобы устранить неполадку. Встаю я значит, расправляю свои админские плечи, и, с высоко поднятой головой, иду ремонтировать свои железки. Нахожу один манюсенький проводочек, воткнутый в манюсенький разъемчик, выключаю его и включаю в другой манюсенький разъемчик. И говорю: “Все, товарищи, работает”. Ну вот должно оно работать в теории. Везде написано, что должно. А оно не работает. Вот приходят ко мне и говорят, что мол обманул я их. Не исправил ничего. А я стою, как говном облитый. Ну ведь должно же работать! Ну тут начинается возня. Чтение документации, звонки друзьям, открытие тикетов в саппорте. В конце-концов приезжает инженер от поставщика и говорит: “а вы вот тут забыли кнопку нажать”. А мы ж, блять, не забыли. Нам не говорили нихуя об этой кнопке. Ну вот и выходит, что я в говне, а инженер в шоколаде, потому, что проблему решил именно он.

Мне кажется эти сраные манюсенькие кнопки специально ставят, чтоб заказчик никогда сам не справился с поломкой. И так это зайобует…

Let’s say you put the software DVD on your central server and mount it up as /SD_CDROM

I tend to do the following (just what I do..)

Stop the swagentd on both boxes.

On the server with the CD/DVD (aka Local)
swreg -l depot /SD_CDROM

On both boxes adjust the access control lists
swacl -l depot -M any_other:crwit
swacl -l host -M any_other:crwit
swacl -l root -M any_other:crwit

Restart your swagent

/usr/sbin/swagentd -r

To check that you can read the CD/DVD you could run:
swlist -d @:/SD_CDROM

Hopefully you get a good response and not an error…

To go to the remote server and run to install from there:
swinstall -s :/SD_CDROM

Для использования нужно разрешить хосту доступ в интернет. Можно использовать SSH туннели или прокси сервер (с авторизацией или без). У меня в сети есть squid. Будем использовать его. Сначала нужно создать /etc/opt/swa/swa.conf. Можно использовать /etc/opt/swa/swa.conf.template как основу.

Вот мой конфиг:

ftp_proxy = ${proxy}
https_proxy = ${proxy}
http_proxy = ${proxy}
proxy = http://proxyhost.mycompany.org:3128
crl_check = false

crl_check отвечает за проверку подлинности сертификатов. Я отключил, поскольку на сервере hp сертификаты не подписаны.

После создания конфига запускаем генерацию отчета:

#swa report

Результат выводится на консоль и сохраняется в html файле ~/.swa/report/swa_report.html. Процесс обследования системы сохраняется в логе /var/opt/swa/swa.log. HTML отчет содержит массу полезных сведений, которые обильно снабжены ссылками на itrc.

После изучения отчета запускаем swa get –t depot_path

вместо depot_path указываем директорию. в которую будут скачаны патчи. Убеждаемся, что в точке монтирования достаточно места (последний quality pack занимает 700 метров плюс дополнительные патчи). В процессе загрузки используется директория /var/opt/swa/cache для кэширования.

После успешной загрузки всех патчей запускаем swinstall –s”depot_path”, выбираем нужные патчи и устанаувливаем.