Рейтинг:1

Определить полный уровень ОС (включая дату сборки) локального репозитория AIX без исправления/установки

флаг br

В нашей среде только одному из наших серверов AIX разрешен доступ в Интернет через брандмауэр. На этом сервере я использую suma для загрузки всех исправлений для всех базовых уровней, технологических уровней и пакетов обновлений, которые есть в нашей среде; это делается ежедневно. Раз в месяц я копирую все исправления вместе в одну папку на базовый уровень и использую инуток для создания пары замороженных репозиториев, которые можно использовать для исправления всех наших серверов AIX. Таким образом, мы можем гарантировать, что все серверы находятся на одном уровне ОС. Мы называем это «ежемесячным набором исправлений».

У нас есть CSV-файл, в котором перечислены все версии ядра для каждого «ежемесячного набора исправлений» для всех наших разновидностей ОС UNIX/Linux. Этот файл CSV используется нашими сценариями исправления/проверки. Для Linux/Solaris я нашел «приемы» для определения версии ядра из самих файлов репозитория, но в AIX мне не удается определить уровень ОС без фактического исправления сервера с его помощью. После исправления я могу запустить 'oslevel -s', чтобы вычислить уровень ОС, но это слишком поздно, так как наши сценарии исправления используют/требуют oslevel до начала фактического исправления.

Кто-нибудь знает трюк, чтобы сделать это? До сих пор я пробовал следующее:

  • Папка нашего репозитория содержит много файлов *.bff, которые являются двоичными файлами, поэтому внутри этих файлов я не могу найти уровень ОС.
  • Имена файлов *.bff в основном представляют собой «U», за которыми следуют некоторые цифры и «.bff» (поэтому их нельзя использовать для определения уровня ОС). Но некоторые имена файлов действительно содержат (части) oslevel в имени файла. Например: 7200-01-06.bff 7200-02-01-1732.bff 7200-02-06.bff 7200-03-06.bff 7200-03.bff 7200-04-01.bff 7200-04-02 .bff 7200-04-03.bff 7200-04.bff 7200-05-01.bff 7200-05-02.bff 7200-05.bff. Однако, как вы можете видеть, в последних версиях oslevel часть «дата сборки» отсутствует в имени файла.
  • Мы патчим с помощью install_all_updates -Y -d <путь_к_репозиторию> команда. я пытался использовать install_all_updates -p -d <путь_к_репозиторию>, надеясь, что это будет видно где-то в выводе, но это не так.
  • я тоже пробовал installp -[lL] -d <путь_к_репозиторию>, но и там oslevel не видно.

Я надеюсь, что кто-то может помочь мне с этим.

Изменить ниже (в ответ на его ответ @Jeff Schaller)

Большое спасибо за вашу помощь!

Это очень близко к совпадению, но, боюсь, не совсем...

--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | grep :bos\.rte\.install: | сортировать -t: -k17n | хвост -1 | awk -F: '{напечатать $3, $17}'
7.2.4.2 1937 г.
root@имя_сервера /nim/export
--> уровень ОС -s
7200-04-01-1939
root@имя_сервера /nim/export

Хотя не знаю, почему... Есть идеи?

Более детально:

--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | грэп 1937 | туалет -л
     613
root@имя_сервера /nim/export
--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | грэп 1939 | туалет -л
       0
root@имя_сервера /nim/export
--> 

Поэтому я подумал, что должен быть установлен какой-то пакет с датой сборки 1939, из-за которого oslevel-s отображает эту дату сборки. Поэтому я выполнил следующие команды, чтобы найти этот пакет:

--> lslpp -Lc все | awk -F':' '{print $2" "$3" "$18}" | грэп 1937 | туалет -л
     288
root@имя_сервера /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> lslpp -Lc все | awk -F':' '{print $2" "$3" "$18}" | грэп 1939 | туалет -л
       0
root@имя_сервера /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> уровень ОС -s
7200-04-01-1939
root@имя_сервера /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> 

Как видите, я не смог найти этот пакет... :(

Изменить № 2 ниже (в ответ на комментарий @Jeff Schaller)

root@имя_сервера /
--> instfix -ic | греп 7200-04 | грэп :-:
root@имя_сервера /

Боюсь, это ничего не вернуло.

Также я не уверен, что именно вы имеете в виду, когда говорите «... сервер понижен до уровня ожидаемой ОС ...». Разве это не наоборот? «oslevel -s» возвращает 1939 год в качестве даты сборки, в то время как все пакеты указывают, что дата сборки должна быть 1937 год. Разве это не «передний уровень»?

Jeff Schaller avatar
флаг nf
Основываясь на вашем обновлении, в котором сервер находится на уровне ниже ожидаемого `oslevel`, я предполагаю, что ему не хватает одного или двух пакетов. Попробуйте `instfix -ic | греп 7200-04 | grep :-:`, чтобы найти неустановленные пакеты, на которые есть ссылки на уровне TL4.
Jeff Schaller avatar
флаг nf
Даты сборки пересекаются с TL/SP — репозиторий — более новый TL4SP2, но работающая ОС — TL4SP1, а у репозитория более старая дата сборки, чем у работающей ОС. Возможно, в репозитории есть пакет, который не установлен в ОС, и есть патч для работающей ОС пакета с более новой датой сборки.
флаг cn
Пожалуйста, объясните еще раз, почему вы не можете запустить `oslevel -s` _до исправления_ только _после него?_
Рейтинг:0
флаг nf

Одним из возможных полезных шагов на этом пути может быть использование bffcreate команда для преобразования этих имен файлов bff в имена файлов на основе пакетов. Что-то в духе bffcreate -c -d /путь/к/хранилищу.

Однако, чтобы ответить на вопрос, как только вы запустите инуток чтобы создать файл .toc, вы можете попросить установка чтобы перечислить содержимое файла TOC этого репозитория в выходных данных, разделенных двоеточиями, которые включают дату сборки в поле 17. Пакет bos.rte.install будет среди тех, у которых самая последняя дата сборки, поэтому вы можете найти его и извлеките его VRMF (версия, выпуск, модификация, исправление) и дату сборки:

sudo installp -L -d /path/to/repo | grep :bos\.rte\.install: | сортировать -t: -k17n | хвост -1 | awk -F: '{напечатать $3, $17}'

Это выведет VRMF и дату сборки самой последней сборки пакета bos.rte.install в этом репозитории. Настроить аук оператор печати, если вас интересует только одно поле или другое. номер сборки в формате YYww (2-значный год, 2-значная неделя этого года). VRMF bos.rte.install примерно соответствует выходным данным костный уровень; возможно, вы могли бы полагаться на первые три поля, чтобы они соответствовали ос-уровень -r вывод; например, VRMF 7.2.4.6 коррелирует с oslevel 7200-04, как и VRMF 7.2.4.2 — начальный 7.2 дает часть «7200», а 4 дает часть «-04».

Рейтинг:0
флаг br

В конце концов, это решение, которое я реализовал (и которое дает мне правильный полный уровень ОС):

Создание репо

  1. Скопируйте все пакеты как *.bff в ${REPO_SNAPSHOT_PATH}
  2. Воссоздайте файл .toc: rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd "${REPO_SNAPSHOT_PATH}" ; инуток .
  3. Очистите репо: /usr/lib/instl/lppmgr -rubxVd "${REPO_SNAPSHOT_PATH}"
  4. Переименуйте файлы bff в понятные имена пакетов: bffcreate -c -d "${REPO_SNAPSHOT_PATH}"
  5. Воссоздайте файл .toc еще раз: rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd "${REPO_SNAPSHOT_PATH}" ; инуток .

Выяснить полный oslevel

  1. Создайте источник LPP из репозитория: nim -o определить -t lpp_source -a server=master -a location="${REPO_SNAPSHOT_PATH}" "${LPP_SOURCE_NAME}"
  2. Создать спот из этого источника LPP: nim -o define -t spot -a source="${LPP_SOURCE_NAME}" -a server=master -a location="${SPOT_PATH}" "${SPOT_NAME}"
  3. Получите полный уровень ОС в этом месте: FULL_OSLEVEL="$(lsnim -l ${SPOT_NAME} 2>/dev/null | awk '$1=="oslevel_s" {print $3}')"

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.