Определение области исполняемого артефакта приложения с помощью мониторинга в OpenVMS

У нас есть устаревшее приложение COBOL, основанное на OpenVMS, для которого у нас нет четкого представления о конфигурации. В этом контексте под «конфигурацией» я имею в виду:

  1. Какие исполняемые файлы составляют приложение;
  2. Какие нетронутые исходные файлы соответствуют исполняемым файлам.

Может показаться странным, что 1 выше — это нечто неизвестное, но со временем произошло то, что исполняемые файлы «появлялись и исчезали» (и многие из них до сих пор используются). Информация о том, какие исполняемые файлы составляют приложение, существующее сегодня, неизвестно, поскольку информация о том, какие исполняемые файлы больше не требуются, со временем утеряна. С практической точки зрения, команда добросовестно компилирует все файлы исходного кода и развертывает полученные исполняемые файлы, несмотря на то, что явно есть программы, которые больше не используются.

Само собой разумеется, что не существует формального процесса управления конфигурацией, а исходный код не хранится в системе контроля версий. Поскольку приложение работает на OpenVMS, соответствующая файловая система на основе Files-11 поддерживает старые версии. файлов (включая исходные файлы), и это долгое время было оправданием для того, чтобы не помещать исходный код приложения в систему контроля версий (несмотря на то, что причины использования VCS выходят далеко за рамки простого наличия записи предыдущих версий).

Конечно, есть несколько способов определить конфигурацию, но я хотел бы начать с первого «маленького шага», а именно: определить набор исполняемых файлов, составляющих приложение. Здесь я должен упомянуть, что исполняемые компоненты приложения не ограничиваются образами OpenVMS, но также и командными файлами DCL. Я хотел бы:

  1. Регистрировать все обращения к изображениям, находящимся в определенном каталоге или наборе каталогов;
  2. Регистрируйте все вызовы командных файлов, которые находятся в определенном каталоге или наборе каталогов.

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

Я думаю, что у меня есть идея, как сделать 1 выше, хотя я не уверен в специфике, то есть использовать SET/AUDIT. Вторую часть, на данном этапе, я понятия не имею, как это сделать.

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

Использование сервисов уровня операционной системы, таких как SET/AUDIT, позволит узнать, что запускается, без необходимости менять исходный код и/или перекомпилировать что-либо. Итак, мой вопрос многопартийный:

  1. Это оптимальный способ сделать это на OpenVMS?
  2. Что мне нужно сделать, чтобы ограничить SET/AUDIT просмотром изображений только в определенном каталоге?
  3. Как мне зарегистрировать вызов командного файла без изменения исходных файлов .COM?
  4. Чего мне следует ожидать в плане снижения производительности в результате регистрации такой информации?

vms openvms dcl
person Eric Smith    schedule 25.11.2015    source источник
comment
Ой. Хорошей отправной точкой для создания дерево зависимостей изображений. Вы можете получить некоторую информацию из set watch file/class=major_function, если он все еще доступен. Если вы имеете дело с кодом, который запускает дополнительные (под)процессы, это может вызвать некоторые, гм, проблемы. Моим любимым было Lib$Find_Image_Symbol для выполнения поздней привязки для необязательных код. Вы чувствуете себя счастливым?   -  person HABO    schedule 26.11.2015
comment
Не было упомянуто, VAX ли это, Alpha или I64. Для Alpha и I64 есть инструмент для печати дерева зависимостей изображений: SHIML - Shareable IMage List. SET WATCH FILE доступен на всех платформах. Это параметр процесса, вам нужны привилегии, чтобы включить просмотр файлов, вам, скорее всего, придется изменить сценарии/командные процедуры, чтобы использовать его, он будет отслеживать все файлы, к которым прикасаются при включении (то есть неисполняемые файлы, файлы, не относящиеся к приложениям и т. д.). . включая общие изображения из sys$library, если они не установлены как открытые известные образы), и вам необходимо перенаправить его вывод в файл журнала.   -  person user2116290    schedule 26.11.2015
comment
Да, я не упомянул платформу: Itanium и OpenVMS 8.4.   -  person Eric Smith    schedule 27.11.2015

Ответы (2)


arrow_upward
5
arrow_downward

Ad 2., 3.

Я бы попробовал аудит безопасности с помощью ACL. С привилегированной учетной записи, что-то вроде...

Убедитесь, что аудит ACL включен:

$ show audit

должен показать

System security audits currently enabled for:
...
ACL
...

Если это не так, включите его с помощью

$ set audit/audit/enable=acl

а затем вы можете отключить его, когда закончите с

$ set audit/audit/disable=acl

Установите контрольные ACL для всех нужных файлов:

$ set sec/acl=(audit=security,access=success+execute) [.app]*.com
$ set sec/acl=(audit=security,access=success+execute) [.app]*.exe

и вы можете захотеть удалить ACL, когда закончите с

$ set security/acl=(audit=security,access=success+execute)/delete [.app]*.com
$ set security/acl=(audit=security,access=success+execute)/delete [.app]*.exe

Вы можете проверить, какие ACL установлены:

$ show security [.app]*.*

Запустите ваше приложение...

Получить результаты из файла аудита

$ analyze/audit [vms$common.sysmgr]security.audit$journal/sel=access=execute/full/since=17:00/out=app.log

Проверьте свой отчет на наличие файлов:

$ pipe type app.log |search sys$pipe "File name", ,"Access requested"
File name:                _EMUVAX$DUA0:[USER.APP]NOW.COM;1
Access requested:         READ,EXECUTE
Auditable event:          Object access
File name:                _EMUVAX$DUA0:[USER.APP]ECHO.EXE;1
Access requested:         READ,EXECUTE
$

Извините, у меня нет ответа на 1. и 4.

person user2116290    schedule 25.11.2015
comment
Спасибо за исчерпывающий ответ; похоже, что аудит командных файлов не является проблемой, то есть просто выполняется так же, как изображения. - person Eric Smith; 26.11.2015

arrow_upward
0
arrow_downward

Было бы полезно узнать версию OpenVMS (например, 6.2, 7.3-2, 8.4...) и архитектуру (Vax, Alpha, Itanium).

Последние версии OpenVMS имеют отличные расширения sda.

http://h71000.www7.hp.com/doc/84final/6549/6549pro_ext1.html

or

http://de.openvms.org/Spring2009/05-SDA_EXTENSIONS.pdf

такие как LNM для проверки логических имен, используемых процессом, PCS для выборки ПК процесса, FLT для проверки ошибочного поведения приложений, RMS для структур данных RMS, PERF только для отслеживания производительности Itanium, PROCIO для чтения и записи для все файлы, открытые процессом

Опубликовать

dir sys$share:*sda.exe

чтобы мы знали, какие расширения Sda доступны для вас.

Вы всегда можете проверить, что делает процесс с pid 204002B4 с

$ ana/sys set proc/id=204020b4 sh process /channel exam @pc

и повторять, пока процесс идет.

person user2915097    schedule 26.12.2015
comment
Версия и архитектура OpenVMS были добавлены в исходный пост в комментарии: Itanium и OpenVMS 8.4. Я не хочу спорить о SDA и его расширениях, и я не знаю, что сделал и намеревается сделать OP, но использование SDA, скорее всего, потребует дополнительной работы для выполнения того, что другие инструменты/функции, такие как ACL и аудит безопасности, уже делать. Кроме того, SHOW PROCESS/CHANNEL является моментальным снимком. Не очевидно, как он может захватывать все общедоступные образы, от которых зависят образы приложений, когда время выполнения конкретного образа приложения короткое. - person user2116290; 27.12.2015
comment
вы можете получать списки открытых файлов для процесса каждую секунду с помощью основного следующего сценария DCL, запускать его с P1 в качестве pid процесса, который вы хотите отслеживать, и P2 в качестве интервала ожидания, который может быть 00:00:01 или меньше, $ say := wr sys$output $ cp = 0 $ loop: $ pipe say "sh proc/id=''P1'/chan" | ana/sys > list_'cp.lis $ wait 'P2 $ cp = cp + 1 $ goto loop например @a 204002B4 00:00:01 - person user2915097; 27.12.2015
comment
если вам нужны более короткие задержки, вы можете использовать P2 00:00:00.01 - person user2915097; 27.12.2015
comment
Конечно, таким образом можно получить список открытых файлов, но какой ценой? Предлагаемая команда pipe создает два процесса, активирует около 10 образов (основной и разделяемый) и записывает один файл. Делая это каждую секунду или даже реже, вы создаете ненужную нагрузку на систему. Для меня делать снимки, независимо от интервала, выглядит неправильным подходом. - person user2116290; 28.12.2015