среда, 18 октября 2017 г.

Опрос: Windows vs Unix

Ссылка на статью
Предыдущий опрос про опыт администрирования SAP систем завершён. Результаты и обсуждение тут.


Предлагаю новый опрос. Представьте, что необходимо установить продуктивную SAP систему. Согласно PAM возможна установка на операционную системы семейства MS Windows и Unix-подобные (Linux, AIX, HP-UX и т.п.). Никаких особых ограничений ни в одной, ни в другой операционных системах со стороны SAP нет. Что вы выберете для продуктивной системы? Ваше личное мнение. Анонимно. :)




Спасибо за участие.
Итоги подведем в середине ноября.

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


понедельник, 16 октября 2017 г.

Создание ярлыка для соединения с SAP системой без пароля

Ссылка на статью
В последнем посте "Саповские секретики - V", в качестве одного из секретов, я рассказывал, как создать ярлык для соединения к SAP системе. При создании ярлыка можно было указать, помимо целевой системы, манданта и языка, транзакцию, которую необходимо запускать сразу после входа в систему. Так же можно было указать имя пользователя, из под которого будет создаваться соединение (рис. 1). Пароль же вводится при открытии соединения через ярлык. И это безопасно и правильно. В данном случае пароль хранится у вас в голове и в SAP системе.

Рис. 1. Создание ярлыка для соединения.

Но, если очень хочется, то можно указать пароль в SAP систему прямо во вновь созданном ярлыке. Для этого необходимо внести изменения в реестр Windows, открыв его командой regedit и добавив по пути HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security параметр "EnablePassword"="1" (рис. 2).

Рис. 2. Внесение изменений в реестр Windows.

Либо можно создать файл-корректировку для реестра (расширение .reg) с содержимым вида:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security]
"EnablePassword"="1"
Выполнить созданный файл, внеся изменения в реестр. И перезапустить программу SAP Logon.

После этого при создании ярлыка для соединения, поле пароля будет открыто на изменение и можно будет внести пароль пользователя, из под которого будет выполняться соединение в будущем (рис. 3).

Рис. 3. Сохранение пароля в ярлыке для соединения.

Вносим пароль пользователя и сохраняем ярлык. После этого вход в систему будет осуществляться без ввода пары пользователь/пароль.

Хотя пароль хранится в ярлыке не в явном виде, всё равно SAP не рекомендуется сохранять его там (рис. 4).

Рис. 4. Пример содержимого ярлыка для соединения с SAP системой.

Функция описана в SAP note # 146173 - SAPShortcut: Saving password in SAPShortcut - not recommended.

В SAP note указано, что, начиная с SAP GUI 7.40 (SP 01) функция была удалена. И экран создания ярлыка в версии SAP GUI 7.50 выглядит без поля пароля вообще (рис. 5).

Рис. 5. Диалоговое окно для создания ярлыка в SAP GUI 7.50.

Но, ярлык, созданный в SAP GUI 7.30 с сохранённым паролем, работает и в SAP GUI 7.50. :)

Но опять же повторюсь, SAP не рекомендует использовать эту функцию.


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


понедельник, 9 октября 2017 г.

Саповские секретики - V

Ссылка на статью
Секретик 1.

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

Рис. 1. Активация информационной части строки состояния SAP GUI.

Правый нижний угол строки состояния SAP GUI содержит много полезной информации. Прежде всего это SID системы, номер режима и номер манданта. Так же там отображается имя хоста (hostname), на котором работает сервер приложений SAP, обслуживающий текущую сессию (рис. 2).

Рис. 2. Полезная информация в строке состояния SAP GUI.

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

Рис. 3. Полная информация о текущем режиме SAP GUI.

Как видно из снимка экрана, присутствует информация по текущему пользователю, запущенным программе и транзакции, а также временные задержки системы. Любую из этих строк можно сделать видимой в строке состояния постоянно, вместо SID системы и номера манданта, которые отображаются по умолчанию. Достаточно выбрать их в выпавшем списке. Например, имя пользователя, из под которого вы работаете в системе (рис. 4).

Рис. 4. Полезная информация в строке состояния SAP GUI: имя текущего пользователя.


Секретик 2.

Еще один полезный совет при работе с SAP GUI. Запуск соединения с SAP системой происходит через утилиту SAP Logon, которая содержит записи о соединениях с SAP системами. Но можно ускорить вход в ваши любимые системы и любимые транзакции. Для этого необходимо войти в необходимой мандант системы, запустить нужную транзакцию (не обязательно, можно указать позже) и нажать на панели кнопку "Создать ярлык" (рис. 5).

Рис. 5. Создание ярлыка для соединения.

В появившемся диалоговом окне заполнить поля и нажать "Готово" (рис. 6).

Рис. 6. Создания ярлыка для запуска соединения.

Здесь можно указать конкретную транзакцию, которую вы хотите сразу видеть на экране, мандант системы, пользователя из под которого вы будете работать, язык входа. В зависимости от того, что вы укажете в поле "Город" (явная ошибка перевода :)), ярлык будет создан или в окне SAP Logon в разделе "Ярлыки" (рис. 7) или, например, на рабочем столе Windows (рис. 8).

Рис. 7. Вновь созданный ярлык в SAP Logon.

Рис. 8. Вход в систему через ярлык.

При запуске ярлыка вводите пароль для пользователя (которого можно изменить) и сразу попадаете в транзакцию, указанную при создании ярлыка.


Секретик 3.

В серии постов про работу с SAP notes (часть 1, часть 2, часть 3) я рассказал про то, что SAP notes, которые содержат коррекции программного кода, часто включают в те или иные пакеты поддержки. То есть, найдя SAP note можно узнать какой пакет поддержки её содержит. Но можно решить и обратную задачу: найти все SAP notes, которые содержатся в том или ином пакете поддержки. Для этого входите на SAP Support Portal в раздел "Software Downloads", находите нужный пакет поддержки и справа от него выбираете пункт "SAP Notes & Side Effects" (рис. 9).

Рис. 9. Дополнительная информация по пакету поддержки.

В открывшемся окне будет список всех SAP notes (разбитых по компонентам), которые включены в данный пакет поддержки (рис. 10).

Рис. 10. Список SAP notes, включенных в пакет поддержки.

Ну и можно найти, например, все SAP notes с изменениями, касательными расчета заработной платы в России (рис. 11).

Рис. 11. Список SAP notes, включенных в пакет поддержки. 

Либо, если вы знаете имя пакета поддержки, можно воспользоваться быстрой ссылкой вида:
https://launchpad.support.sap.com/#/supportpackage/<SP_name>
здесь <SP_name> - имя пакета поддержки.


Предыдущие выпуски:
Саповские секретики - I,
Саповские секретики - II,
Саповские секретики - III,
Саповские секретики - IV.


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


понедельник, 2 октября 2017 г.

Почему SAP рекомендует 3-х системный ландшафт?

Ссылка на статью
Вот вы говорите: "Ландшафт, ландшафт... " А что такое ландшафт?

Давайте остановимся на этом понятии поподробнее.

Итак, в посте "Копирование манданта SAP системы" я приводил структуру данных SAP системы (рис. 1).

Рис. 1. Структура данных в SAP системе.

В ABAP части SAP системы выделяют автономные единицы для работы и хранения данных предприятия. Данные единицы носят название - мандант. Мандант содержит основные данные (Master Data), записи пользователей с полномочиями и манданто-зависимые настройки. Манданты идентифицируется троичным номером и их в системе может быть несколько. Теоретически 1000 штук.

Помимо манданта, в системе есть общие для всех мандантов данные: манданто-независимые настройки и репозитарий SAP системы. Репозитарий это прежде всего ABAP-программы (reports, функциональные модули, экраны и т.п.). К репозитарию так же относится и ABAP-словарь, про который я писал в посте "Транзакция SE14 : утилита базы данных".

Ландшафт, как я уже упоминал ранее, это объединение нескольких систем одного назначения/версии для настройки/обеспечения контроля качества/поддержки того или иного решения компании SAP. Например, SAP ERP 6.0 EHP7 (кстати, самая распространенная версия по опросам) или SAP SRM 7.0 EHP3.

Ландшафты SAP систем могут быть:
  • одно системными,
  • двух системными,
  • трех системными.

Рассмотрим первый вариант - ландшафт SAP системы, состоящий из одной системы. Допустим, в одном манданте системы разработчики и консультанты производят настройки и пишут/изменяют ABAP-программы. А второй мандант системы выделен для работы пользователей (рис. 2).

Рис. 2. Одно системный SAP ландшафт.

В плане разграничения доступа - всё хорошо. Пользователи в разных мандантах разные. И консультанты и разработчики не имеют доступ к основным данным предприятия (например, заработной плате), так как работают в отдельном манданте. Но представьте, что будет, если разработчик активирует новую версию программы при работающих с ней пользователях? Будет несколько дампов (равных количеству работающим с программой пользователей) и все результаты работы пользователей будут потеряны. Так как, еще раз повторюсь, репозитарий для нескольких мандантов одной системы только один, он общий (рис. 2). 

Я в своей практике встречался с таким ландшафтом. Это был пилотный проект в одном, отдельно взятом, подразделении крупного транспортного предприятия. В день, когда на проект приходил разработчик, пользователи в системе не работали. :) То есть получалась система с разграничением времени работы: либо пользователи, либо ABAP-программист.


Второй вариант: в ландшафте SAP системы уже 2 системы. Одна играет роль системы разработки и настройки, вторая для продуктивной работы пользователей. Системы объединены транспортной системой (рис. 3). 

Рис. 3. Двух системный SAP ландшафт.

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

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


Поэтому переходим к последнему варианту - 3-х системный ландшафт. Три системы (DEV, QAS, PRD) работают в связке, объединенные, корректно настроенной, транспортной системой. Такая связка обеспечивает независимость разработки и настройки в первой системе, тестирование разработанного решения и переноса транспортного запроса во второй и безопасный перенос готового, оттестированного решения в систему промышленной эксплуатации (рис. 4).

Рис. 4. Трёх системный SAP ландшафт.

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

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

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

Стоит еще отметить: систем в ландшафте может быть больше. Например, 2 тестовые системы, с разным срезом продуктивных данных. 2 продуктивные системы, которые поддерживаются одной парой разработка-тест.

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

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

P.S. Всё что здесь описано, касается только AS ABAP, при разработке в AS JAVA требования к ландшафту несколько другие. Подробности можно найти в курсах SAP ADM325 и SAP ADM800.




четверг, 28 сентября 2017 г.

SAP на Linux: на какой дистрибутив можно поставить систему?

Ссылка на статью
SAP системы дружат с Linux давно. Если клиентское место SAP GUI for Java, которое можно установить на любую операционную системы (Winodws, Linux или MacOS), но прежде всего на Linux, не является самым популярным решением (в отличии от версии SAP GUI для Windows). То Linux, как платформа для серверной части SAP системы, является бесспорно отличным вариантом. Причем, переход на Linux намечается и со стороны HP, в рамках перехода на x86_64 платформу и уход от HP-UX, и со стороны поклонников Solaris, как результат планомерной политики Oracle, купившей Sun. Один жирный плюс Linux это его универсальность и не зависимость от конкретного вендора железа. А где независимость и универсальность, там конкуренция и экономия.

Если мы обратимся к таблицам совместимости продуктов SAP, операционных систем и баз данных, а именно к Product Availability Matrix (PAM), то увидим, что почти все продукты SAP поддерживают установку на Linux. Причем, Linux может работать на большом количестве аппаратных платформ (x86_32, x86_64, zSeries, Power) в паре почти с любой базой данных. Исключение составляет разве что MS SQL Server, который работает только на Windows Server.

Напоминаю, что про PAM я писал в одноимённом посте.

Старые продукты, такие как SAP R/3 4.6C работали на Linux, последние версии SAP ERP 6.0 EHP8 или, например, SAP Solution Manager 7.2 на базе SAP HANA работают на Linux (рис. 1, 2 и 3).

Рис. 1. Страница PAM: SAP ERP 6.08 на Linux и MaxDB.

Рис. 2. Страница PAM: SAP ERP 6.08 на Linux и Oracle.

Рис. 3. Страница PAM: SAP Solution Manager 7.2 на Linux и SAP HANA.

Как я уже упоминал, на данный момент SAP поддерживает 3 версии дистрибутива Linux:

Последний, как это видно из примеров страниц PAM (рис. 1 и 2), поддерживается только при использовании базы данных Oracle. Зато первые два универсальны и работают даже с новой базой данных от SAP, использующей вычисления in-memory, - SAP HANA. Версии операционных систем, которые поддерживаются SAP HANA описаны в SAP note # 2235581 - SAP HANA: Supported Operating Systems.

Все три дистрибутива коммерческие. Получать обновления и поддержку производителя можно только при оплате контракта. Исключения ORACLE Linux и его бесплатное распространение, включая обновления. Но поддержка так же платная.
И это логично. Система SAP серьёзное программное обеспечение и требует серьезного подхода. Только при таком подходе можно гарантировать бесперебойную и корректную работу всей системы.

Версии коммерческих дистрибутивов, поддерживаемых SAP, можно найти в SAP note # 2369910 - SAP Software on Linux: General information.

Для работы продуктивных систем предприятия, даже я бы сказал, продуктивных ландшафтов, подходят только коммерческие дистрибутивы, поддерживаемые компанией SAP.
У компании есть SAP LinuxLab, в которой тестируются Linux-ядра, указанных выше дистрибутивов. И SAP рекомендует использовать только их, без добавления модулей или перекомпиляции. Подробности в SAP note # 784391 - SAP support terms and 3rd-party Linux kernel drivers.

Но иногда хочется срезать углы, попробовать что-то необычное, новое, поэкспериментировать.

Если задуматься, то что такое дистрибутив Linux? Это набор ПО (ядро Linux, библиотеки, базовые утилиты, дополнительное ПО), распространяемый в своём формате пакетов, с набором тех или иных уникальных инструментов для установки и настройки. Таким образом, взяв за основу любой дистрибутив Linux, немного доработав его, мы получим базовую ОС для установки SAP системы?

К тому же, вы наверное знаете, что у Red Hat Enterprise Linux есть два близких родственных свободных дистрибутива - это CentOS и Fedora. Первый считается вообще почти полной копией.
У SUSE Linux Enterprise Server есть OpenSuse. И RHEL, и SLES с их родственниками основаны на rpm-пакетах. Есть еще огромная армия дистрибутивов, основанных на rpm.
Да, и дистрибутивы основанные на deb-пакетах (Debian, Ubuntu и т.п.) не сильно отличаются.

И у меня возник вопрос: а кто нибудь пробовал устанавливать SAP системы на не коммерческие дистрибутивы? CentOS? OpenSuse? Ubuntu? Какие дополнительные шаги были необходимы? Как стабильно работала система? Напишите в комментариях к посту. Я думаю, что всем будет интересен ваш опыт.

В Интернете нашел опыт установки системы SAP R/3 на AltLinux (rpm-based) и, даже, на FreeBSD! :)

P.S. напоминаю также про опрос "Опыт администрирования SAP систем", который закончится в середине октября (на данный момент зафиксированы голоса 23-х человек). Если не участвовали, то просьба - поставьте галочку для статистики. :)

Спасибо.


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


понедельник, 25 сентября 2017 г.

Анализ места на диске в Unix

Ссылка на статью
Как вы знаете из поста "35 лет или как я попал в SAP", я начинал свою профессиональную карьеру с администрирования Unix систем. И я обожаю Unix. Во всём многообразии систем, называемых Unix-подобными, мне нравится ядро, концепция, которая лежит в основе их всех, начиная от AIX и заканчивая Linux.

Сегодня хочу остановиться на файловой системе.

В операционной системе Unix файловая система это отдельный столп, на котором базируется ядро этой системы.

В Windows, в отличии от Unix, понятие файловой системы не выходит на первый план. Есть набор дисков, которые подключены к компьютеру или серверу. Каждый диск имеет привязку к букве латинского алфавита. Без этой привязки работать с диском операционная система не сможет. А уже внутри диска создается файловая система. В Windows это может быть FAT, HPFS или NTFS. Подробности про них можно посмотреть тут.

Рис. 1. Пример жестких дисков в операционной системе Windows.

В Unix есть единый корень файловой системы: "/" (root). Это начало всего. Не зря суперпользователь в Unix так же носит имя "root". Все остальные файловые системы монтируются, как ветки общего дерева.

Это ещё не всё. Все объекты в Unix это файлы. С точки зрения программиста, программа обращается к файлу с помощью четырех системных вызовов: open(), read(), write() и close(). Таким образом, всё, с чем можно работать через данные вызовы, это файлы. Хотя, например в Linux, файлы в каталоге /proc не существуют физически. Это лишь представление внутренних данных ядра в виде файлов. Но работать с ними можно как с файлами. Это просто, универсально и удобно.

В операционной системе Unix есть следующие типы файлов:
  • обычный файл (или жесткая ссылка),
  • каталог,
  • символическая ссылка,
  • блочное и символьное устройства,
  • именованный канал и доменный сокет Unix.

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

Каталоги это тоже файлы. Файлы, содержащие список имён файлов с ссылками на inode (рис. 2). 

Рис. 2. Схема хранения файлов в Unix.

Inode хранит атрибуты файла, такие как тип файла, владелец, группа, права доступа, временные метки, и указатели на блоки данных. Про права доступа в Unix я писал в посте "Oracle + Unix: полномочия на директории". Пока на inode файла существует хоть одна жесткая ссылка, файл удален не будет. Стоит еще отметить, что таблица inodes существует в рамках файловой системы и жесткие ссылки могут быть созданы только внутри одной файловой системы.

Для указания на файлы из других файловых систем существуют символьные ссылки. Которые не что иное, как просто указатель на существующий файл в каком-либо каталоге. Пример использования символьных ссылок на файлы устройств для ленточной библиотеки я описывал в посте "Подружить кластер и brbackup/brarchive".

Блочные и символьные устройства - это файлы, через которые можно работать с теми или иными физическими устройствами. Например, устройство записи на магнитные ленты (символьное), жесткие диски (блочное).

Именованные каналы и сокеты используются для организации взаимодействия между разными программами.

Тип файла отображается в результатах команды ls, в виде первого символа перед правами доступа (рис. 3).

Рис. 3. Пример вывода команды ls.

Прочерк - признак обычного файла, d - каталога, l - ссылки и так далее.

Команда find, про которую я рассказывал в посте "HP-UX. Многоликая команда find", может помочь найти те или иные типы файлов. Например, сокеты (рис. 4).

Рис. 4. Пример вывода результатов поиска сокетов Unix.

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

В посте "Файл-пустышка" я уже затрагивал эту тему применительно к одной директории. Я рассказал как создать небольшую заглушку в директории, содержащей оффлайн журналы Oracle. Чтобы в случае заполнения файловой системы до 100% срочно освободить немного места одной командой. В ситуациях отсутствия необходимого пространства в данной директории - это место нужно, как глоток свободного воздуха. Иначе база данных Oracle просто "подвиснет", как и SAP система, которая работает на ней.

Просмотреть место в файловых системах поможет команда df (рис. 5).

Рис. 5. Пример вывода команды df в операционной системе Linux.

Данная команда показывает общее количество блоков (1 Кб), занятых (в Кб и процентах) и свободных блоков по каждой смонтированной файловой системе.

В операционной системе HP-UX более читабельной является команда bdf (рис. 6).

Рис. 6. Пример вывода команды bdf в операционной системе HP-UX.

Если свободное пространство где-то резко уменьшилось, то необходимо выяснить кто и чем его занял. В этом случае поможет команда du. Например,
 # du -ks ./* 
отобразит все каталоги в текущей директории и занимаемое ими пространство в файловой системе в Кб (рис. 7). Опция -k - отображает результаты в Кб, а ключ -s - диктует отображать только суммарное значение занимаемого пространства по каждой директории.

Рис. 7. Пример списка каталогов в директории /var с их размерами.

Еще очень хороший вариант (рис. 8):
 # du -xks / 
Рис. 8. Пример вывода команды, отображающей занимаемое пространство в корневой файловой системе.

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

Таким образом, при выявлении проблем с пространством в файловых системах Unix необходимо руководствоваться следующим алгоритмом:
  1. С помощью команд df (bdf) проанализировать файловые системы и свободное пространство в них.
  2. Перейти в необходимую файловую систему и проанализировать пространство, занимаемое каждой директорией, с помощью команды du с необходимыми опциями.
  3. Спуститься по дереву каталогов до конца, собрав информацию по пространству.
  4. Принять решение по удалению файлов, если это возможно, или расширению файловой системы.

Так же для поиска старых, самых больших или определённых файлов (например, дампов core) можно воспользоваться командой find, про которую я писал в посте "HP-UX. Многоликая команда find".

Дополнительные ключи и опции команд Unix или Linux всегда можно найти в справке man, набрав команду вида:
 # man <command_name> 

P.S. Для Linux есть различные графические утилиты, которые помогают визуализировать занимаемое пространство. Но еще раз повторюсь, команды из командной строки это самый универсальный инструмент, который есть во всех дистрибутивах, версиях и более или менее постоянен.




четверг, 21 сентября 2017 г.

Пользователь TMSADM

Ссылка на статью
При начальной конфигурации транспортной системы в AS ABAP любой SAP системы в 000 манданте автоматически создаётся системный пользователь TMSADM.

Данный пользователь имеет тип "Communication" или "System" (рис. 1). Но ни в коем случае не "Диалоговый", то есть вход в систему через SAP GUI ему должен быть запрещен.

Рис. 1. Тип учетной записи TMSADM.

Дело в том, что для работы транспортной системы используются RFC-соединения (рис. 2). Эти RFC-соединения генерируются так же при первоначальной настройке транспортной системы (TMS).

Рис. 2. RFC-соединения, использующиеся в работе транспортной системы.

RFC-соединения используются для обмена информацией между системами транспортного ландшафта (рис. 3).

Рис. 3. Схема настройки RFC для работы транспортной системы.

Как видно из схемы и рис. 2, используется 2 вида RFC-соединений:
  • TMSADM@<SID>.<DOMAIN_NAME> - для аутентификации используется пользователь TMSADM, используется для некритичных операций, прежде всего на чтение информации;
  • TMSSUP@<SID>.<DOMAIN_NAME> - используется для более критичных операций, прежде всего операций записи, для аутентификации требует пару пользователь/пароль.

Эти два вида RFC-соединений создаются в каждой системе, которая подключена к транспортному домену. И пользователь TMSADM есть в каждой, но только в 000 манданте.

Так как пользователь TMSADM генерируется автоматически, то для него хранится стандартный пароль, который знают все системы транспортного ландшафта. В разных версиях SAP систем использовались два вида паролей:
  • PASSWORD;
  • $1Pawd2&.

Начиная с версии системы SAP NetWeaver 7.40, при настройке транспортной системы можно задать свой пароль. Или выбрать один из стандартных вариантов паролей (рис. 4).

Рис. 4. Установка пароля для пользователя TMSADM.

Установка своего пароля удовлетворяет требованиям безопасности, но старые системы в одном ландшафте с такой системой работать не смогут. Хотя ситуация работы систем разных версий в одном ландшафте очень редка, всё равно выбор оставили.

Проверить пароль пользователя TMSADM, не трогая учетную запись, можно через отчёт RSUSR003. Данный отчет проверяет пароли системных пользователей во всех мандантах системы на предмет их безопасности. То есть, в программе есть список хэшей стандартных паролей, которые он сверяет с реальными в системе. Например, для пользователей SAP* и DDIC, про которых я писал в этом посте.

Результатом работы отчета будет список системных пользователей и вердикт по их паролям (рис. 5).

Рис. 5. Проверка паролей системных пользователей.

Если отчёт в системе не отображает информацию по пользователю TMSADM, то необходимо заглянуть в SAP note # 1552894 - RSUSR003: Checking the standard password for user TMSADM. Установив исправления из ноты или соответствующий пакет поддержки для вашей версии системы, получите новую версию отчёта, которая проверяет пароль для пользователя TMSADM. Как работать с SAP нотами я описывал в цикле статей - часть 1, часть 2, часть 3.

Просто так, войдя в транзакцию SU01, изменить пароль для TMSADM нельзя. Как правильно изменить стандартный пароль для пользователя TMSADM описано в SAP note # 1414256 - Changing TMSADM password is too complex.

Дополнительно на данную тему можно найти информацию в курсе SAP "ADM325 - SAP Software Logistics for ABAP" и SAP note # 761637 - Logon restrictions prevent TMSADM logon.