С наступающим Новым 2021 Годом!

 

Всех, кто читает мой блог постоянно или заглядывает сюда лишь изредка, хочу поздравить с наступающим Новым Годом!

Оглядываясь назад, могу назвать уходящий год годом обучения и сертификации. После участия в 2019 году в проекте построения программно-аппаратного комплекса, где использовалась среда виртуализации VMware, я задумался о поднятии своих навыков в этом направлении. Но самый необычный год в жизни, наверное, каждого из нас, внёс свои коррективы. В итоге, я переключился на новую цель - сертификацию как SAP Basis специалиста. Усилия не прошли даром, и в декабре, как вы уже знаете, я успешно сдал экзамены на 3 сертификата.

Ещё в этом году я подготовил и опубликовал третий пакет своего обучающего курса SAPADM 2.0.

Что касается свободного времени, то в этом году я решил провести эксперимент и читать книги только по работе и личному развитию. В итоге, я считаю, что это было ошибкой. На много больше литературы по рабочим навыкам я не осилил, а вот общее количество прочитанного за год резко упало. С большой натяжкой можно говорить лишь о 18 книгах за год. При этом лишь 8 из них были по моей специальности. 

В итоге, из художественной литературы могу посоветовать только Арчибальда Кронина и его роман "Цитадель". Книга очень похожа на серию книг Юрия Германа, которые я читал в 2019 году. А из фильмов советский мини-сериал "Воскресенье, половина седьмого", сценарий для которого написал Анатолий Рыбаков. 

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

Надеюсь, что этот год для вас также не прошёл впустую. Уверен, что каждый из вас найдёт то, что он сделал в этом году и чем он может хоть немного гордиться или даже похвастаться. :) 

Желаю всем здоровья, финансового благополучия и хорошего настроения! Поменьше читать негативных новостей и газет, больше хороших книг и фильмов! Хорошо вам отдохнуть за праздники, перезагрузиться и быть готовым к новым задачам и свершениям! 

Ну и старайтесь придерживаться баланса в жизни: ни лениться, но и не перегружать себя. Уделяйте своё время и телу и уму, физическому и умственному, работе и отдыху. Не переживайте о скорости движения вперёд. Главное, что вы двигаетесь. Дорогу осилит идущий.

До встречи в следующем году! 

Без вас не было бы и мне смысла писать в этот блог. 

Спасибо, что читаете.

Автор: Шиболов Вячеслав Анатольевич

Плюс сертификат C_TADM55_75

В эту субботу, 12 декабря 2020 года, я сдал последний из запланированных мною на этот год сертификационных экзаменов - C_TADM55_75 - SAP Certified Technology Associate - System Administration (SAP HANA as a Database) with SAP NetWeaver 7.5. 

В итоге, оформив один раз подписку на Certification Hub, я потратил 3 попытки и успешно сдал 3 сертификационных экзамена. И у меня ещё осталось 3 попытки на следующий год.

По времени сдача этого экзамена у меня заняла также около 50 минут. Многие вопросы, как и следовало ожидать, пересеклись с предыдущими экзаменами. В результате 77% верных ответов. Проходной бал был 62%. 

На этом свою эпопею с сертификацией в этом году заканчиваю. :)

Если кому-то нужна помощь в подготовке к этим экзаменам, пишите мне на почту shibolov@gmail.com.

Автор: Шиболов Вячеслав Анатольевич

Плюс сертификат C_TADM55A_75

Вчера, 9 декабря 2020 года, я сдал ещё один сертификационный экзамен C_TADM55A_75 - SAP Certified Technology Associate – System Administration (SAP HANA) with SAP NetWeaver 7.5. 

Сдавал так же через Certification Hub. 

Затраты времени составили порядка 50 минут. Многие вопросы пересеклись с предыдущим экзаменом, что я сдавал 5 дней назад. Результат - 86% верных ответов. Тема SAP Fiori опять лишь только на 38%. 

Порог для сдачи всего экзамена - 63% правильных ответов. 

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

Рис. 1. Результаты экзамена C_TADM55A_75.

Обычный формат (A4) сертификата пока не прислали. Ни на первый экзамен, ни на второй. Новый формат, бейджи о сдаче, присылают сразу. Посмотреть их можно на этом сайте. Там же их можно проверить на действительность через сайт SAP SE, разместить в социальных сетях или на своём сайте/блоге.

Действительно формат онлайн сдачи через облако позволяет, хорошо подготовившись, сдать несколько экзаменов. :)

Автор: Шиболов Вячеслав Анатольевич

Сдача сертификационного экзамена C_TADM51_75

Сегодня, 4 декабря 2020 года, я сдал сертификационный экзамен C_TADM51_75 и стал SAP Certified Technology Associate – System Administration (Oracle DB) with SAP NetWeaver 7.5. 

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

В этот раз (в очередной раз спасибо пандемии) экзамен сдавал онлайн. У SAP появился такой сервис как Certification Hub. Данный продукт является подпиской, которая предоставляет доступ к облаку SAP, в котором можно планировать и сдавать сертификационные экзамены. Подписка стоит около 44 000 рублей и оформляется на 1 год на одного человека. После оформления подписки есть 6 попыток для сдачи экзаменов. На каждый сертификационный экзамен можно потратить не больше 3-х попыток. После 3-х неудачных попыток данный экзамен для данного человека блокируется и сдавать его, до выхода новой версии, нельзя. Сделано это ограничение, наверное, чтобы человек не разбил себе лоб пытаясь сдать экзамен. :) При хорошем стечении обстоятельств, человек может по одной подписке получить 6 сертификатов, готовясь и сдавая их в течении года. 

Мне эту подписку оформил портал SAPLAND бесплатно, как автору статей. За что им (особенно Михаилу Сковородину и Вере Шевченко) ещё раз большое спасибо. 

При сдаче экзамена через Certification Hub необходимо заранее запланировать дату и время сдачи экзамена. Выбрать можно в формате 24/7, что очень удобно. В назначенный день уединиться в отдельной комнате с ноутбуком или компьютером, убрав всё со стола. Сдача экзамена происходит через специальное программное обеспечение, которое разворачивается на весь экран, блокируя другие приложения. А через Zoom (камера, микрофон, колонки) за вами следит англоговорящий проктор, который в начале проверяет ваше окружение и идентифицирует вашу личность по документам (например, водительским правам). Потом 3 часа даётся на сдачу. Результаты видны сразу на экране. 

В этот раз я отстрелялся за 1 час 10 минут. Вопросы были сложные, со старыми ничего общего. В результате - 76% верных ответов. Подвела тема SAP Fiori, в которой у меня не так много опыта. К слову, для сдачи необходимо было набрать 62%. Готовился по своим старым вопросам с 2012 года и материалам SAP курсов, рекомендованных к экзамену. 

В планах сертификационные экзамены C_TADM55a_75 и C_TADM55_75. Я думаю, что вопросы там похожие, а у меня ещё 5 попыток. Если после этого останутся попытки, то запланирую что-то ещё.

В общем, дерзайте. Формат удобный. А я принимаю поздравления. :)

P.S. Подготовка к экзаменам не давала часто писать в блог в последнее время. Теперь постараюсь исправиться.

Автор: Шиболов Вячеслав Анатольевич

Ошибка ORA-28000: the account is locked

Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.

Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. SAP GUI выдавал сообщение о том, что база данных системы недоступна. 

Первая мысль была: "Ну, наверное, по какой-то причине затянулся бэкап". Но переход на уровень операционной системы сервера показал, что база данных запущена, а процессов резервного копирования в операционной системе нет. Правда, со стороны Oracle работают только фоновые служебные процессы и нет ни одного shadow-процесса. 

Вы наверное знаете, что при оффлайн резервной копии базы данных (или как её ещё называют "холодный" бэкап) процессы ABAP инстанции не останавливаются, а остаются работать, потеряв коннект к базе данных. При этом рабочие процессы с настойчивостью и периодичностью пытаются открыть соединение к базе данных. Поэтому, как только база данных становится доступной для соединения, рабочие процессы открывают соединения, а Oracle запускает для каждого рабочего процесса SAP инстанции отдельный shadow-процесс. Подробнее о том, как рабочие процессы SAP системы подключаются к базе данных я описывал в статьях: "Как рабочие процессы SAP соединяются с базой данных Oracle - I" и "Как рабочие процессы SAP соединяются с базой данных Oracle - II". 

Так вот, shadow-процессов Oracle не наблюдалось. Я подключился к базе данных через SQLPlus, используя пользователя SYSTEM. Соединение установилось успешно. На всякий случай перестартовал базу данных. Проверил: shadow-процессов как не было, так и нет. При этом рабочие процессы SAP инстанции в списке процессов операционной системы висели.

Хорошо. Последний рестарт SAP системы был давно, вдруг что-то подглючило на уровне сервера приложений, подумал я. И решил перезапустить сервер приложений. Но скрипты запуска системы выдают: "База данных не запущена, будем запускать. Попытка запуска базы данных заканчивается ошибкой - "база данных недоступна". Стоит отметить, что скрипты запуска SAP системы для проверки доступности базы данных используют утилиту R3trans, входящую в состав SAP Kernel, запуская её с опцией "-d" (рис. 1 и 2).

Рис. 1. Пример успешной проверки соединения с базой данных.

Рис. 2. Пример безуспешной проверки соединения с базой данных.

Проверка переменных окружения пользователей, настроек Oracle client, процесса Listener ничего не дала. 

И только в третий раз просматривая журналы рабочих процессов SAP инстанции (файлы dev_w*), обратил внимание, что код ошибки при попытках коннекта к Oracle отличается от типичного. Когда база данных остановлена, выдаётся код ошибки 1034. 

Рис. 3. Пример кода ошибки соединения с остановленной базой данных.

А тут выдавался код 28000 (рис. 4). 

Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

По коду ошибки удалось выяснить, что ошибка заключается не в недоступности Oracle, а в блокировке пользователя. Как вы уже знаете, из вышеупомянутых статей, что рабочие процессы SAP системы при подключении к Oracle используют пользователя владельца схемы в базе данных. В данном случае это пользователь SAPSR3. Так вот этот пользователь и оказался заблокированным. 

К блокировке пользователя привёл параметр базы данных Oracle - FAILED_LOGIN_ATTEMPTS. Начиная, с версий Oracle 10g значение данного параметра, по умолчанию, равно 10. В предыдущих версиях СУБД по умолчанию стоит значение UNLIMITED. Посмотреть значение в текущей базе данных можно запросом вида:

SQL> select LIMIT from DBA_PROFILES where PROFILE='DEFAULT' AND RESOURCE_NAME='FAILED_LOGIN_ATTEMPTS';

или

SQL> show parameter FAILED_LOGIN_ATTEMPTS;

Как вы помните из моего поста, при соединении с базой данных, до версии Oracle 11g в SAP системе использовался механизм хранения пароля пользователя владельца схемы в отдельной табличке OPS$<USER>.SAPUSER. Так как в момент оффлайн бэкапа база данных недоступна, то рабочий процесс не может получить к ней доступ и прочитать продуктивный пароль пользователя. И как видно из скриншота (рис. 3), каждый раз делается ещё и дополнительная попытка открыть соединение с дефолтным паролем, который зашит в коде ядра. Допускаю, что случилась такая ситуация, что в момент старта базы данных было сделано больше 10 попыток логина к базе данных со стороны SAP системы с этим стандартным паролем (который отличается от продуктивного пароля). В результате этого Oracle автоматически заблокировал пользователя (владельца схемы) и последующие попытки SAP системы присоединиться к базе данных проваливались уже по этой причине, вплоть до моего вмешательства. 

Разрешение ситуации: разблокировка пользователя. Разблокировать пользователя можно в SQLPlus командой вида:

SQL> alter user SAPSR3 account unlock;

После этого рабочие процессы корректно подключаются к базе данных. Для предотвращения возникновения ситуации в будущем -  установка параметра в большее значение, вплоть до UNLIMITED. Сделать это можно SQL-командой вида:

SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 50;

Со стороны компании SAP ситуация описана в SAP note 951167 - ORA-28000: the account is locked.

P.S. Думаю, что описанная ситуация довольно таки редкая и возможна только в узком круге версий систем SAP и базы данных Oracle. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.

Автор: Шиболов Вячеслав Анатольевич

С наступающим днём знаний 2020! Скидки на авторские курсы обучения SAP Basis

Поздравляю всех с наступающим днём знаний!

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

Ну и по традиции, в связи с праздником, скидка на пакеты моего обучающего курса SAPADM 2.0. Напоминаю, что курс абсолютный новый, полностью переписанный и основанный на версии SAP NetWeaver 7.50 и платформе Linux/Oracle. 

Тому, кто напишет мне на почтовый ящик shibolov@gmail.com до 23:59 6 сентября 2020 года, я отдам любой пакет курса за 12 000* рублей. 

То есть с учётом скидки все три пакета нового курса обойдутся всего за 36 000* рублей (вместо 48 000).

Условия акции:

* - для получения забронированных пакетов со скидкой, их надо будет оплатить до конца сентября 2020 года.

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

Автор: Шиболов Вячеслав Анатольевич

Запись вебинара "Технологическая архитектура SAP HANA"

Наткнулся недавно на отличный вебинар по архитектуре SAP HANA. Отличие от большинства бесплатных вебинаров по этой теме от компании SAP AG или вендоров оборудования в том, что в данном видео освещены именно технические детали системы. Маркетинга практически нет. Докладчик: Сергей Кузин из SAP AG.

Вот собственно само видео:

Презентацию можно скачать по этой ссылке.

Дополнительно ещё могу посоветовать полезное видео на тему построения отказоустойчивых решений для систем на SAP HANA:

Есть проблемы со звуком, но контент очень интересный и полезный.

P.S. У кого есть похожие материалы, просьба поделиться в комментариях. Спасибо.

Автор: Шиболов Вячеслав Анатольевич

Пятничный юмор

Любой программист очень любит отлаживать и править чужие программы. :)

За картинку спасибо Александру Тельпуку.

Если у вас есть забавные иллюстрации для публикации в пятничном юморе, присылайте мне на электронную почту - shibolov@gmail.com.


Автор: Шиболов Вячеслав Анатольевич

Core файлы большого размера

Периодически почти в любой SAP системе возникают ошибки, дампы и сбои. Не возникает их, наверное, только в системе, где никто не работает. А для надёжности в системе, которая вообще выключена. :)

Бывает ситуация, когда рабочий процесс ABAP инстанции "падает" с кодом ошибки 11, а в SAP системе формируется динамическая ошибка типа SYSTEM_CORE_DUMPED (рис. 1).

Рис. 1. Пример дампа SYSTEM_CORE_DUMPED.

В результате сбоя рабочий процесс останавливается, а на уровне файловой системы в рабочей директории инстанции (/usr/sap/<SID>/<Instance>/work/) образуется файл, содержащий дамп памяти и имеющий имя - core. Рабочий процесс обычно автоматически перезапускается диспетчером и о фактах рестарта мы можем узнать только по счётчику "Ошб." на экране транзакции SM50 (рис. 2).

Рис. 2. Информация о рестарте рабочего процесса в результате сбоя.

Про поиск core файлов на уровне операционной системы я писал ещё в посте "HP-UX. Многоликая команда find". Данная команда одинаково работает в любой Unix или Linux системе. Но иногда файлы core имеют большой размер и могут даже переполнить файловую систему (рис. 3).

Рис. 3. Пример core файла на уровне операционной системы.

В моём примере файл core имеет размер 39 Гб, что составляет более половины размера файловой системы. Если же на ваших серверах приложений данная файловая система имеет размер недостаточный для создаваемых файлов дампов и, из-за этих файлов часто происходит переполнение файловой системы, то можно после очередного удаления файла core создать его заранее в виде линка на /dev/null (рис. 4).

Рис. 4. Решение по хранению больших core файлов.

В этом случае всё содержимое core файла будет уходить в никуда, не занимая места ни в одной из файловых систем сервера.

Автор: Шиболов Вячеслав Анатольевич

Бесплатные вебинары от SUSE Russia

Натолкнулся недавно на сайте Youtube на канал российского представительства компании SUSE и хочу с вами поделиться. Канал называется SUSE Russia и на нём выложены все вебинары, которые проводит компания.

Ссылка на канал: SUSE Russia.

Некоторые видео могут быть интересны. 

Например, на вебинаре "SUSE Linux Enterprise Server 15" рассказывают какие отличия появились с этой версии дистрибутива. Одна из них это единый инсталлятор для всего портфолио продуктов, основанных на SUSE Linux Enterprise Server. Поэтому-то образ и увеличился до почти 10 Гб. Вот видео-запись вебинара:

А в записи вебинара "SUSE Enterprise Server 15 SP1" рассказывают про новую возможность обновления системы - Transactional Update, которая появилась именно с этого Service Pack. Посмотреть всё видео можно тут:

Про более интересный для нас SUSE Linux Enterprise Server for SAP Applications есть отдельный вебинар:

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

Ну и смотреть можно на 1,5х скорости. :)


Автор: Шиболов Вячеслав Анатольевич

SysAdminDay - 2020

Всех причастных с праздником!

Желаю:
Стабильной работы систем! 
Меньше рутины, но больше интересных задач!
Уважения коллег и руководства!
Удовольствия от работы и материальных благ!


Автор: Шиболов Вячеслав Анатольевич

Вебинар "Решения Fujitsu и Red Hat для SAP HANA"

В прошлый вторник, 21 июля, присутствовал на вебинаре "Сотрудничество для достижения успеха: Решения Fujitsu и Red Hat для SAP HANA". Открыл для себя несколько интересных моментов и хочу ими поделиться.

В первой части вебинара от компании Fujitsu выступал бессменный консультант по бизнес-приложениям Николай Гришин (рис. 1). А от компании Red Hat архитектор по решениям Дмитрий Алехин представил свою презентацию во второй части.

Рис. 1. Николай Гришин из компании Fujitsu.

Компания Fujitsu использует в своих решениях Linux, в частности для SAP систем, уже больше 20 лет. Первый проект, в котором она принимала участие, был 1999 году и в нём работала система SAP R/3 4.0. Измеренный уровень производительности был 241 SAPS (рис. 2).

Рис. 2. Первые инсталляции SAP на Fujitsu/Linux.

Их современные серверные решения показывают гораздо больший уровень производительности (рис. 3).

Рис. 3. Сервера PRIMEQUEST - рекорды производительности.

В решениях компании активно используется новый тип энергонезависимой памяти - Intel Optane DC persistent memory (DCPMM) (рис. 4).

Рис. 4. Память Intel Optane DC.

Утверждается, что использование данного типа памяти отлично ложится на концепцию SAP HANA и позволяет получить выигрыш, в первую очередь, при рестарте базы данных (рис. 5).

Рис. 5. Преимущества использования Intel Optane DCPMM в SAP HANA.

Вторая часть вебинара, как я уже упоминал, была посвящена решениям Red Hat. 

К свою стыду, впервые узнал, что у компании  Red Hat есть готовые решения операционных систем для разворачивания SAP систем. И существуют они уже с 2008 года (рис. 6). Наивно полагал, что такие готовые решения (for SAP Applications) есть только у SUSE.

Рис. 6. История партнёрства Red Hat и SAP.

  

У RHEL for SAP Applications есть практически те же опции и решения, что и у SLES: встроенные программные модули для отказоустойчивости, увеличенный срок поддержки, встроенные профили для быстрого разворачивания и мониторинга, а также Live Patching (рис. 7).

Рис. 7. RHEL for SAP Solutions.

Причём, на данный момент существует два вида подписок "RHEL for SAP Applications" и "RHEL for SAP Solutions" (рис. 8). Сравнение этих редакций RHEL тоже были освещены в вебинаре.

Рис. 8. Сравнение двух редакций.

Поэтому рекомендую ознакомиться с материалами вебинара. Архив с видеозаписью и презентациями можно скачать по этой ссылке.

Автор: Шиболов Вячеслав Анатольевич

Уязвимость в SAP AS Java: ошибка RECON

Сегодняшний пост будет про безопасность, а именно про уязвимость RECON.

Если вы внимательно следите за медиа-ресурсами, то про новую "страшную" дыру в безопасности SAP под названием RECON, наверняка, слышали. Но проблема в том, что часть журналистов, как обычно, "слышала звон и спала в одном ботинке...".

Давайте разбираться вместе.

1. Дыра есть - это факт. Ошибка RECON является серьёзной. Это одна из тех редких уязвимостей, которые получили максимум 10 из 10 оценок по шкале серьезности уязвимостей CVSSv3.
2. Уязвимость проста в использовании и находится в компоненте, которая по умолчанию включена в каждую SAP систему, в которой работает Java стек SAP NetWeaver. А именно, в компоненте мастера настройки LM (LM Configuration Wizard) сервера приложений SAP NetWeaver.
3. Подвержены "дыре" AS Java системы с версии 7.3 до самых новых. Про более древние ничего не говорят (они уже давно EOL), но возможно и с ними есть проблемы. Для тех, кто не помнит, SAP системы в основном представлены 3 основными типами платформ: AS ABAP (ECC/BW), AS Java и HANA. Есть ещё экзотика, типа BusinesObjects или Hybris, но их удельный вес настолько мал, что про них можно забыть. Таким образом, уязвимость охватывает системы SAP S/4HANA, SAP SCM, SAP CRM, SAP Enterprise Portal и SAP Solution Manager. Во всех них встречается AS Java часть.
4. Используя ошибку, можно получить доступ к системе, просто создав учетную запись пользователя SAP с максимальными привилегиями для приложений SAP, представленных в Интернете. 

Поэтому, на наш взгляд, стоит обратить внимание на данную проблему. Если AS Java у вас в ландшафтах отсутствует, то тогда можно расслабиться. А если же, ваша AS Java часть системы смотрит в сеть Интернет (и доступна из него!), то сразу стоит остановить службу LM (SAP note 2939665). А после этого стоит остановить Java системы и пропатчить их (SAP note 2934135).

Описание проблемы в SAP note 2947895 - RECON - SAP Vulnerability.

Закрытие дыры и патчи описаны в SAP note 2939665 - Disable/Enable LM Configuration Wizard | Critical API's in LM Configuration Wizard и SAP note 2934135 - [CVE-2020-6287] Multiple Vulnerabilities in SAP NetWeaver AS JAVA (LM Configuration Wizard).

После этого уже никакой RECON вам будет не страшен!


Авторы: Бондарев Дмитрий, Шиболов Вячеслав Анатольевич

Как рабочие процессы SAP соединяются с базой данных Oracle - II

В первой части статьи я описал как в SAP системе рабочий процесс, используя двух этапный механизм, определяет пароль владельца ABAP схемы (SAP<SCHEMA-ID>) и подключается с помощью этого пользователя к базе данных Oracle.

Такой механизм использовался до версии Oracle 11g. Но с выходом базы данных Oracle 11g оказалось, что это последняя версия СУБД от Oracle, которая поддерживает OPS$-механизм для удалённого соединения с ней. В связи с этим компания SAP также внесла поправки в работу своих приложений. И начиная с SAP kernel Release 7.20 (примерно с 100 пакета поддержки) представила новый метод для хранения пароля владельца базы данных и соединения с ней. В SAP kernel Release 7.20 зашифрованный пароль для пользователя базы данных может хранится не в базе данных, а на уровне файловой системы. Такой способ называется Secure Storage in File System (SSFS). 

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

Рис. 1. Пример сообщений из журнала рабочего процесса при коннекте с базой данных новым способом.

Для того, чтобы рабочие процессы и внешние утилиты SAP (R3load, R3trans) использовали новый метод, необходимо в DEFAULT профиль SAP инстанции добавить ряд параметров (рис. 2). Про профили и параметры SAP системы я уже рассказывал в своё время в статьях (1, 2).

Одновременно должны быть установлены переменные окружения пользователя операционной системы <sid>adm (рис. 3).

Рис. 2. Параметры SAP инстанции, связанные с SSFS способом коннекта. 

Рис. 3. Переменные окружения пользователя ОС для SAP системы, связанные с SSFS способом коннекта. 

На уровне операционной системы в директории /usr/sap/<SID>/SYS/global/security созданы специальные директории и файлы со строгими правами на доступ (рис. 4). В файле SSFS_<SID>.DAT хранится как раз информация необходимая для соединения с базой данных, включая зашифрованный пароль владельца схемы.

Рис. 4. Список директорий и файлов, хранящих информацию для соединения с базой данных.

Для просмотра содержимого хранилища в SAP Kernel есть утилита rsecssfx. Набрав одноимённую команду, можно получить список всех записей (опция list) или содержимое отдельной записи (опция get). Содержимое записи с паролем зашифровано и не будет показано в целях безопасности (рис. 5).

Рис. 5. Пример использования команды rsecssfx.

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

Для обратной совместимости, вплоть до версий SAP Kernel 7.38 и базы данных Oracle 11.2, поддерживается одновременно и старый, двух этапный, метод. Хотя SAP уже в этих версиях рекомендует переходить на новый метод хранения пароля на уровне файловой системы. Ведь сделать это можно даже в системах на базе SAP NetWeaver 7.0, так как эти программные продукты поддерживают SAP Kernel 7.20. Переход на это ядро я описывал в одноимённом посте.  

И стоит иметь в виду, что если в Oracle 11g установить параметры профиля REMOTE_OS_AUTHENT=TRUE, то при старте инстанции в терминале или в системном журнале можно увидеть сообщения об ошибке вида:

• ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance,
• ORA-32006: REMOTE_OS_AUTHENT initialization parameter has been deprecated.

Эти сообщения можно проигнорировать, так как не смотря на них старый механизм всё ещё будет работать. Необходим он, если в UNIX системах утилиты SAP BR*Tools и рабочие процессы SAP всё ещё используют OPS$-механизм, который и требует установки параметра REMOTE_OS_AUTHENT=TRUE. 

Ну а начиная с SAP Kernel 7.40 поддерживается только SSFS механизм хранения пароля пользователя SAP<SCHEMA-ID>.

Для смены пароля владельца схемы необходимо пользоваться SAP утилитами BR*Tools (версия не ниже 7.20 пакет поддержки 28). Команда вида:

> brconnect -u / -f chpass 

изменит пароль и в системных таблицах Oracle, и в защищенном SSFS хранилище.

Есть правда небольшой нюанс на переходных системах, там где возможна работа обоих методов. Такая команда при выполнении проверит есть ли таблица OPS$<USER>.SAPUSER. И если она ещё существует в базе данных, то пароль пользователя изменится в ней, а новое хранилище SSFS будет проигнорировано. Поэтому при переходе на новый метод необходимо эту таблицу удалить.

Либо в команде BRCONNECT можно использовать дополнительную опцию "-s|-secstore", где можно указать поменять пароль для коннекта рабочими процессами ABAP инстанции. Например, командой вида:

> brconnect -u / -c -f chpass -o SAPSR3 -p <new_password> -s abap 

При использовании этой опции пароль будет изменён именно в SSFS хранилище, а наличие таблицы OPS$<USER>.SAPUSER будет проигнорировано.


OPS$-механизм, который я описывал в прошлой части может быть использован не только для удалённого соединения, но и для локального. И даже в версиях Oracle 12c и выше локальное соединение с использованием OPS$-механизма всё еще поддерживается. Его могут использовать, например, утилиты BR*Tools или администратор при выполнении операций с базой данных (в утилите SQLPlus). 

Но если вы хотите от него отказаться окончательно, то можно его заменить на специального пользователя BRT$ADM, с помощью которого утилиты из набора BR*Tools и будут открывать соединение и  выполнять задачи по администрированию базы данных. После создания такого пользователя OPS$-пользователей из базы данных можно окончательно удалить. Подробности про этот переход и про работу BR*Tools, включая вопросы смены пароля владельца схемы в SSFS, можно найти в SAP note # 1764043 - Support for secure storage in BR*Tools.

Также на данную тему советую изучить SAP notes:

• 1611877 - Support for ABAP SSFS during database connect,
• 1622837 - Secure connection of AS ABAP to Oracle via SSFS,
• 1639578 - SSFS as password store for primary database connect.

В них детально описано как перевести систему на новый метод хранения пароля и соединения с базой данных. 

Стоит ещё отметить, что SSFS механизм хранения пароля владельца схемы используется не только при разворачивании системы на Oracle, но и при работе с Sybase ASE, SAP HANA и SAP MaxDB (см. SAP note 1639578).

А если хотите погрузиться в администрирование базы данных Oracle на практике, то добро пожаловать в мой авторский курс по SAP Basis. 

Автор: Шиболов Вячеслав Анатольевич

Как рабочие процессы SAP соединяются с базой данных Oracle - I

Как вы знаете, основными "рабочими лошадками" SAP инстанции являются рабочие процессы (SAP Work Processes или WP), которыми управляет диспетчер. В случае с AS ABAP это ABAP диспетчер. При использовании с SAP системой СУБД Oracle рабочие процессы SAP инстанции для корректной работы должны соединиться с базой данных. После открытия соединения каждому рабочему процессу SAP будет соответствовать один процесс на уровне СУБД, так называемый shadow-процесс.
При этом на сервере приложений SAP на уровне операционной системы рабочие процессы запускаются и работают под пользователем <sid>adm (в UNIX) или SAPService<SID> (в случае Windows). В свою очередь все таблицы и индексы в базе данных, которые используются текущей SAP системой, принадлежат одному пользователю базы данных. Этот пользователь называется владельцем схемы (которая объединяет все таблицы и индексы) и имеет имя SAP<SCHEMA-ID>. Стандартно в SAP инсталляциях имя владельца схемы - SAPSR3,  но иногда может быть SAP<SID>, а в старых системах пользователь носил имя - SAPR3 (до версии SAP Basis 4.6D). Владельца схемы в текущей инсталляции можно определить, если на начальном экране в системе выбрать пункт меню «Система -> Статус…» (рис. 1 и 2).

Рис. 1. Просмотр владельца схемы в базе данных.

Рис. 2. Пример владельца схемы в базе данных.

Для получения полного доступа к таблицам базы данных рабочие процессы SAP инстанции должны соединяться именно под этим пользователем. Данный пользователь на уровне Oracle (как и любой другой) защищён паролем. Но рабочие процессы SAP не знают этот пароль, так как это пользователь другого уровня, не уровня сервера приложений. Поэтому в своих решениях для рабочих процессов SAP использует механизм, который позволяет узнать пароль владельца схемы в процессе создания соединения. Об этом механизме я и хотел сегодня рассказать.

Данный механизм основан на сохранении пароля пользователя SAP<SCHEMA-ID> не только в системной таблице Oracle (в которой хранятся пароли всех пользователей на уровне базы данных), а еще и в специальной таблице. Специальная таблица имеет имя SAPUSER, и принадлежит схеме другого пользователя базы данных - OPS$<SID>ADM (в UNIX) или OPS$<DOMAIN>\<SID>ADM (в Windows). В Windows, к этой таблице также имеет доступ пользователь OPS$<DOMAIN>\SAPService<SID>, от которого и работают рабочие процессы SAP, как я написал выше.

Небольшое отступление про OPS$-пользователей (OPS$<USERS>) или OPS$-механизм базы данных Oracle. При разворачивании SAP системы, на этапе установки базы данных Oracle, программа установки спрашивает пароли для создаваемых пользователей: SYS, SYSTEM и SAP<SCHEMA-ID>. Это отдельные пользователи базы данных, которые создаются на уровне Oracle. Но помимо этих пользователей, программа установки создаёт отдельную группу пользователей, которые используют механизм Oracle, называемый "OS authentication". Эти пользователи имеют префикс "OPS$" и содержат имя пользователя операционной системы. Для UNIX систем это OPS$<SID>ADM, OPS$ORA<SID> и, в последних релизах Oracle, OPS$ORACLE. А для Windows соответственно OPS$<DOMAIN>\SAPService<SID> и OPS$<DOMAIN>\<SID>ADM. Заметьте, что в случае с Windows обязательное условие это добавление домена в имя OPS$-пользователя. Если сервер не в домене, то используется hostname сервера (рис. 3). 

Рис. 3. Пример списка пользователей базы данных Oracle, развернутой в ОС Linux.

OPS$-механизм разрешает пользователям операционной системы (для которых создан соответствующий OPS$<USER>) соединяться с базой данных без ввода пароля. То есть аутентификация пользователя переносится на уровень операционной системы, где и проводится проверка пароля.

Для активации OPS$-механизма необходима установка двух параметров инстанции Oracle:

• REMOTE_OS_AUTHENT=TRUE – разрешает удалённое соединение (OS authentication) для тех пользователей операционной системы UNIX, у которых в базе данных есть соответствующий OPS$-пользователь. То есть соединение возможно с любого компьютера в сети, с которого возможно открыть соединение с базой данных,
• OS_AUTHENT_PREFIX=OPS$ - начальный префикс для таких пользователей в базе данных. Для SAP систем значение по умолчанию "OPS$".

Теперь вернёмся к вопросам соединения рабочих процессов SAP инстанции к базе данных Oracle.

SAP инстанция может работать как на том же сервере, где работает сервер базы данных, так и на отдельном сервере. Поэтому при старте рабочего процесса он не знает: база данных доступна локально или удаленно. Следовательно в Oracle должен быть разрешён удаленный логин (параметр REMOTE_OS_AUTHENT). Стоит сразу обозначить, что в целях обеспечения безопасности права OPS$-пользователя ограничены. Он может лишь присоединиться к базе данных и прочитать запись только в таблице SAPUSER, так как эта таблица принадлежит ему. Читать, добавлять или изменять данные в других SAP таблицах (в основной схеме базы данных) ему запрещено.

Рис. 4. Схема соединения рабочих процессов SAP к базе данных Oracle.

Когда рабочий процесс SAP запускается и пытается соединиться с базой данных Oracle, он выполняет следующие шаги (рис. 4):

1. Рабочий процесс открывает коннект к базе данных как соответствующий OPS$-пользователь с аутентификацией на уровне операционной системы.
2. С помощью SQL-запроса SELECT к таблице SAPUSER рабочий процесс читает пароль пользователя SAP<SCHEMA-ID>.
3. Текущее соединение с базой данных Oracle закрывается.
4. Рабочий процесс открывает новое соединение с использованием уже пользователя SAP<SCHEMA-ID> и пароля, который он получил на предыдущем этапе из таблицы SAPUSER.

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

А вот как этот процесс коннекта к базе данных выглядит на уровне сообщений журнала рабочего процесса SAP (рис. 5).

Рис. 5. Пример журнала рабочего процесса SAP.

Также стоить добавить, что такой двух этапный механизм коннекта к базе данных используют не только рабочие процессы, но и некоторые SAP утилиты. Например, R3trans или R3load. 

Для смены пароля владельца схемы (пользователь SAP<SCHEMA-ID>) нельзя использовать методы базы данных Oracle (например, команду password) (рис. 6). Так как в этом случае пароль изменится только в системных таблицах Oracle, а в таблице OPS$<USER>.SAPUSER останется старым и рабочие процессы не смогут соединиться с базой данных (рис. 7).

Рис. 6. Пример смены пароля владельца схемы методами Oracle.

Рис. 7. Пример ошибки при попытке рабочего процесса открыть соединение с базой данных.

Чтобы смена пароля не привела к ошибкам в работе системы, для этой операции необходимо использовать утилиты BR*Tools (в старых системах - SAPDBA). Про эти утилиты я писал в этой статье. Утилита от SAP изменит пароль владельца схемы не только в системных таблицах Oracle, но и таблице OPS$<USER>.SAPUSER. А это обеспечит корректную работу описанного выше механизма соединения рабочих процессов (рис. 8 и 9).

Рис. 8. Корректный способ смены пароля владельца схемы - 1.

Рис. 9. Корректный способ смены пароля владельца схемы - 2.

А если обратить внимание, что на нижнем уровне в brtools запускается утилита BRCONNECT, то пароль можно сменить, запустив эту программу напрямую одной командой вида:

> brconnect -u / -f chpass 

Хотя пароль владельца схемы в таблице SAPUSER и хранится в зашифрованном виде, рекомендую дополнительно ознакомиться с рекомендациями по организации более безопасной инфраструктуры, прочитав SAP note #157499 - OPS$ connect and security aspects. Там описано, например, как ограничить список IP-адресов машин, с которых возможен удалённый коннект к серверу базы данных, используя OPS$-механизм. 

А начиная с Oracle 11g была прекращена поддержка со стороны Oracle OPS$-механизма для удалённого подключения и, SAP (начиная с SAP Kernel 7.20) стал использовать новый механизм для организации соединения рабочих процессов SAP и базы данных. Но об этом я расскажу уже во второй части статьи. 

Автор: Шиболов Вячеслав Анатольевич