RE: установка фиксов


Главная Форумы POWER Systems AIX/Hardware установка фиксов RE: установка фиксов

#9625

Alexander Tchoulkov
Участник
Aliexpress INT

К сожалению ничего не могу сказать по поводу Oracle инсталлятора, не использовал уже несколько лет, но помнится (смутно) что у него была опция при запуске не обращать внимание на установлены или нет фиксы и всё равно устанавливать. Или то было у Informix. Не помню, может и ни у того и ни у другого:)

Про APAR’ы. Рассказ будет некороток.

Грубо говоря AIX имеет как бы две поддержки (это одна поддержка но она имеет существенную особенность касающуюся iFix которую для понимания сложности процесса поддержки можно мысленно выделить в отдельную. Но в реальной жизни стратегия поддержки AIX одна):
1. Это поддержка AIX. Дату до которой поддерживается конкретная версия можно увидить по адресу:

http://www-01.ibm.com/software/support/lifecycle/

по этому жу адресу можно узнать даты поддержки (General Availability – дата когда был официально объявлен продукт. С этого момента собственно поддержка и начинается и End of Support дата когда поддержка на продукт будет прекращена). Если дата “End of Support” не указана, то дата прекращения поддержки ещё не определена. Получить поддержку после даты “End of Support” можно, но по отдельному специальному контракту (extended support)

2. дата до которой выпускаются iFix’ы. Что такое iFix – это временный фикс для какой либо известной проблемы для которой ещё нет фикса в вышедшем TLXX SPXX или заказчик по какой либо причине не может перейти на TL SP который содержит исправление. Так вот iFix’ы выпускаются программистами по заказам технической поддержки под конкретного заказчика и конкретную машину (исключение фиксы HYPER это отдельная история) и выпускаются только для 3-4 последних TL’ов. Даты до которых выпускаяются iFix’ы для конкретных TL’ов не публикуются так как могут часто меняться. Ещё одна характеристика iFix’ов это то что они проходят минимальное тестирование (в основном из за сжатых сроков выпуска).

В результате получаем множество поддерживаемых “версий”, например для AIX 6.1:

AIX 6.1
|
+– TL1
|
+– TL2
|

|
+– TL4
|
+– TL5
|
+– TL6

Допустим что, iFix’ы выпускаются начиная с TL4. Что в этом случае происходит:
1. заказчик обращается в техническую поддержку
1.1 у него AIX c уровнем TL для которого выпускаются iFix’ы:
1.1.1 техническая поддержка анализирует инцищент и если в результате анализа выясняется, что это проблема кода, тогда проверяется не содержит ли какой либо TL SP фикс для устранения этой проблемы.
1.1.2 если содержит тогда техническая поддержка рекомендует обновиться как минимум до соответствующего уровня TL SP
1.1.3 если исправления для этой проблемы ещё нет в ни в одном TL SP, и у заказчика TL для которого поддерживается выпуск iFix и для этого TL ещё не было аналогичных обращений. Регистрируется новый APAR, т.е. проблеме присваивается уникальный номер и этот номер ПРИВЯЗАН К ВЕРСИИ + TL.
1.2 у него AIX с уровнем TL для которого ну выпускаются iFix’ы. В этом случае техническая поддержка рекомендует перейти на AIX с TL для которого выпускаются iFix’ы и если инцидент по которому производилось обращине повторится с новым уровнем ТL, тогда обратиться в техническую поддержку повторно.

Это крайне упрощённое описание процесса регистрации проблем в коде и выпуска фиксов для них. В принципе здесь нет ничего необычного аналогичные процессы описаны в ITIL и методологиях управлением разработкой программного обеспечения.

В результате очень часто получается, что одно и тоже проявление проблемы имеет разные номера (APAR) для разных TL при этом может быть создан обобщающий APAR содержаций ссылки на конкретные APAR’s.

Что касается инсталлятора который проверяет только определённые номера APAR могу сделать предположение исходя из опыта технической поддержки, управления системами и разработки программного обеспечения о совокупности причин почему инсталлятор проверяет только определённые номера APAR:

1. При разработке больших систем выбираются базовые версии средств разработки и окружения. В том числе и операционной системы. И как правило ни версия операционной системы (включая обновления которые не являются критичными для работы ОС) ни средства разработки не изменяются в течении всего процесса разработки и тестирования новой версии программного обеспечения. Соответственно в инсталляторе отражены номера TL которые были включены в ОС до начала разработки инсталлятора.
2. Программисты как правило испытывают очень большое давление по срокам и им некогда отслеживать выпуск фиксов для ОС
3. Для некоторых TL APAR’ы были зарегистрированы после выпуска инсталлятора

Посему не думаю, что это кривизна. Это ограниченность ПО к которой приходится прибегать для обеспечения максимально возможной стабильности программного обеспечения при заданных стоимости и времени разработки (времени выхода на рынок).

Теперь о соответствии какой APAR для какого TL. Я о таком списке не знаю, подозреваю что его просто не существует в виду сложных взаимозависимостей и процессов которые я очень упрощённо описал выше. НО есть доступная база которая позволяет определить какой APAR для какого TL это Fix Central:

http://www-933.ibm.com/support/fixcentral/

1. Переходим на него
2. Выбираем в “Product Group” -> “Power”
3. Выбираем в “Product” -> “AIX”
4. Выбираем в “Version” -> Нужную версию например 5.3
5. Выбираем в “Fix Type” -> “Fix search”
6. Нажимаем “Continue” и переходим на страницу “Fix Search”

Для примера введём номер IZ45795. Результат поиска:
1. Fix pack information for: GLOB() LIBC ROUTINE IS NOT THREADSAFE
Z42940 bos.rte.shell 5.3.9.1 bos.rte.security 5.3.9.2 bos.rte.libc 5.3.9.2 bos.adt.prof 5.3.9.2 bos.64bit 5.3.9.3 bos.rte.control 5.3.9.1 IZ45795 bos.rte.libc 5.3.10.0 bos.adt.prof 5.3.10.0 bos.rte.shell 5.3.10.0 bos.rte.security 5.3.10.0 bos.rte.control 5.3.10.0 bos.64bit 5.3.10.0 IZ45374 bos.rte.shell 5.3.11.0 bos.64bit 5.3.11.0 bos.adt.prof 5.3.11.0 bos.rte.libc 5.3.11.0 bos.rte.security 5.3.11.0 bos.rte.control 5.3.11.0 IZ69996 bos
Modified date 2010-09-17
2. IZ45795: GLOB() LIBC ROUTINE IS NOT THREADSAFE APPLIES TO AIX 5300-10
The glob() library routine is thread-unsafe, as it will unexpectedly change current directory inside of it for a
Modified date 2010-03-29
3. IZ42940: GLOB() LIBC ROUTINE IS NOT THREADSAFE APPLIES TO AIX 5300-09
The glob() library routine is thread-unsafe, as it will unexpectedly change current directory inside of it for a
Modified date 2010-03-29

В этом случае под номером 1 у нас есть “обобщенный APAR”

под номерами 2 и 3 мы нашли варианты для 5300-10 и для 5300-09.

если перейти по ссылке 1 на “обобщенный APAR”

мы увидим таблицу:

в первом столбце “package” ссылка на пакет для загрузки
во втором столбце “level shhiped” он содержит уровень AIX в котором поставляется фикс
в третьем столбце “APAR/Filesets” как раз и указан номер APAR который соответствует этому уровню AIX

В случае если “обобщённого APAR’а” в списке поиска нет, тогда нужно больше действий 🙂
Предположим, что мы в результате поиска “IZ45795” получили только один единственный результат который в предидущем поиске был под номером 2:

IZ45795: GLOB() LIBC ROUTINE IS NOT THREADSAFE APPLIES TO AIX 5300-10
The glob() library routine is thread-unsafe, as it will unexpectedly change current directory inside of it for a
Modified date 2010-03-29

переходим по ссылке и видим описание APAR.

сейсас в этом описании нам интересны три поля:
1. самое верхнее “A fix is available” которое содержит к нашему счастью ссылку “Obtain the fix for this APAR” для нашего случая переход по ней приведёт опять к таблице с выбором для разных уровней AIX. Но в случае если обобщённого APAR нет переход приведёт к странице загрузки соответствующего TL SP из которой мы и определим какому TL соответствует APAR

2. APAR is sysrouted FROM one or more of the following: IZ42940
3. APAR is sysrouted TO one or more of the following

поля 2 и 3 это связанный список APAR’ов которые относятся к данной проблеме и переходя по ним мы также можем определять какой APAR к какому уровню AIX относятся.

Ещё одно поле в описании APAR это “PTF to Fileset Mapping” в котором мы так же видим какая версия задействована в этом APAR. Например, для APAR IZ42940 оно содержит:

U819998 bos.rte.shell 5.3.9.1
U819999 bos.rte.security 5.3.9.2
U820000 bos.rte.libc 5.3.9.2
U820014 bos.adt.prof 5.3.9.2
U824770 bos.64bit 5.3.9.3
U824771 bos.rte.control 5.3.9.1

для нас сейчас интересен третий столбец который содержит полную версию:
первые две цифры – версия AIX 5.3
третья одна цифра – TL 9
четвёртая – SP мы видим 1, 2 и 3 нам нужна максимальная это SP3

Итак AIX 5.3 TL9 SP3

Такое определение выглядит несколько сложным в изложении но на практике это просто.

PS: Таким образом фиксы для инцидентов которые которые проверяет Oracle у Вас установлены. И пробелем которые адресуются этими APAR’ами у Вас не будет. С другой стороны лучше проконсультироваться с Oracle поддерживают ли они TL SP который у Вас установлен и не нужни ли дополнительные фиксы для Oracle и/или AIX.
Причины по которым инсталлятор проверяет только определённые номера APAR’ов тоже понятны. Это особенности существующих ныне процессов разработки, эксплуатации и поддержки программного обеспечения.