admin
Java plugin в новой версии ubuntu 11.10
0Из репозиториев удалили SUN/Oracle Java и теперь автоматически через apt установить родную Java машину нельзя.
Если нужен джава-плагин в FireFox делаем так:
1) Качаем джаву с сайта Oracle: http://www.java.com/ru/download (вариант Linux самораспаковывающийся файл)
2) Делаем сохраненному файлу chmod a+x jre-6u31-linux-i586.bin
3) Заходим в /opt (или другую директорию по выбору) и от рута запускаем файл /tmp/downlods/jre-6u31-linux-i586.bin
4) Джава в системе установлена. Нужно сделать сслку на плагин для Firefox: cd ~/.mozilla/plugins; ln -s /opt/jre1.6.0_31/lib/i386/libnpjp2.so
5) Перезапускаем Firefox и открываем старницу about:plugins
6) Если всё установлено правильно, то видим:
Java(TM) Plug-in 1.6.0_31
Файл: libnpjp2.so
7) Для проверки работоспособности плагина заходим на страницу http://www.java.com/ru/download/installed.jsp и нажимаем кнопку «Проверьте версию Java».
AUTH_MAXTRIES
0account locked due to maximum login failures:
if file «/etc/default/security» set attribute «AUTH_MAXTRIES=3″
after login prompt receive message:
«Access is denied by the AUTH_MAXTRIES attribute in security(4).»
to unlock type^
userdbset -d -u username auth_failures
extend fabric with domain conflict
0- switchdisable
- cfgdisable
- cfgclear
- configure, set/check all fabric parameters this must be the same as all other switch in the Fabric, excepted DID
- defzone --allccess
- switchenable
- portstatsclear
- portlogclear
Reboot the switch.
Ubuntu 11.04/11.10 X server -nolisten_tcp
0Вариант для версии 11.04:
В этой версии убунты оказалось достаточно сложно разрешить xorg’у слушать сеть.
Это связано с переходом на новую врсию GDM.
Для включения сетевого режима работы X сервера необходимо создать файл /etc/gdm/custom.conf и в него вставить такие строки:
[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
Датапротектор и сеть с файрволом
0
Итак нам дано:
1) host A — клиент, на котором нужно забэкапить файловую систему.
2) host B — медиа агент, который подключен к ленточной библиотеке и находится в другом конце города.
3) host C — Сел мэенеджер датапротектора. Находится в третьем здании.
Все хосты соединены по IP сети, которая защищена файрволами.
Проблема заключается в том, что после успешного бэкапа в датапротекторе сессия закрывается со статусом 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
После включения кипэлайвов сессии перестали обрываться и бэкап работает как часы :)
DataProtector reset «Poor» medium
0Бывает, что DataProtector помечает ленту как «Poor» после неудачного бэкапа. Чтобы вернуть ленте состояние «Good» нужно выполнить команду:
omnimm -reset_poor_medium NW0101L4
Последний параметр — это лэйба ленты.
Сбросить состояние всех «Poor» лент библиотеки:
for f in `omnirpt -report media_list | grep LIBNAME: | grep Poor | awk '{print $2}'`; do omnimm -reset_poor_medium $f; done
unlock hp-ux v.3 account
0When an account has been locked due to too many authentication failures, root can unlock the account by this command:
userdbset -d -u username auth_failures
Использование DataProtector для копирования базы.
0
Есть задача скопировать базу данных с хоста 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’е
Мошенники
0
Вот работаю я в одной крупной конторе. Рулю не менее крупным оборудованием. И все в этом оборудовании прекрасно – и внешний вид, и внутренняя идеология, и программы, с помощью которых этим оборудованием можно управлять, и обучение по этому оборудованию.
Привозят, скажем, новый сервер, новый дисковый массив, новый FC коммутатор. Собираем это все вместе, включаем и, о чудо! Оно работает. Устанавливаем туда свои программы, пользуемся ими. И тут, вдруг, происходит нечто. Что-то такое, чего вполне можно было ожидать и все готовы к такому происшествию. Тема выхода из строя обсуждалась при планировании, при закупке, во время обучения. Есть документация, есть умные программы. Есть все, чтобы устранить неполадку. Встаю я значит, расправляю свои админские плечи, и, с высоко поднятой головой, иду ремонтировать свои железки. Нахожу один манюсенький проводочек, воткнутый в манюсенький разъемчик, выключаю его и включаю в другой манюсенький разъемчик. И говорю: “Все, товарищи, работает”. Ну вот должно оно работать в теории. Везде написано, что должно. А оно не работает. Вот приходят ко мне и говорят, что мол обманул я их. Не исправил ничего. А я стою, как говном облитый. Ну ведь должно же работать! Ну тут начинается возня. Чтение документации, звонки друзьям, открытие тикетов в саппорте. В конце-концов приезжает инженер от поставщика и говорит: “а вы вот тут забыли кнопку нажать”. А мы ж, блять, не забыли. Нам не говорили нихуя об этой кнопке. Ну вот и выходит, что я в говне, а инженер в шоколаде, потому, что проблему решил именно он.
Мне кажется эти сраные манюсенькие кнопки специально ставят, чтоб заказчик никогда сам не справился с поломкой. И так это зайобует…
swacl
0To install using one central depot, where we are not talking about Ignite-UX depots, you need to set up software access lists giving the remote server permissions. It makes so much easier then running around. I load most everything off my CD/DVD using my old workstation under my desk…..
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 @
Hopefully you get a good response and not an error…
To go to the remote server and run to install from there:
swinstall -s
список wwid всех lunов
0scsimgr -p get_attr all_lun -a device_file -a wwid
HP-UX software updates
0Свежие патчи можно получать с помощью HP-UX Software Assistant (продукт B6834AA swa), который заменил Security Patch Check. Продукт идет в комплекте с 11i V3.
Для использования нужно разрешить хосту доступ в интернет. Можно использовать 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”, выбираем нужные патчи и устанаувливаем.