Linux Patching with AWS Systems Manager


AWS Systems Manger can be used to perform many administration tasks. One of its functionalitis is Linux system patching. The decision if a packet should be updated is based on assotiated patch baselines. Curently AWS has defined default baselines for Windows, Amazon Linux, RedHat and Ubuntu. Bellow I will show how to create/configure the nedded resources to start a patching session and verify the patch complience status of a Linux instance.

Preparing rights

The instance that will be patched needs to be a part of a role that will allow the ssm agent running on the instance to communicate with AWS infrastructure. Following steps will create the needed role:

  • In the AWS console go to IAM->Roles and click on “Create Role”
  • Select EC2 Role fro Simple Systems Manager


  • Click on “Next: Review”2
  • Chose a name for example “SSMManaged” and click on “Create Role”

In this post I will show how to start the patching process manualy from the console. To do so the user that will initiate the patching and verify the results will need some specyfic permissions. In this case i will go with AmazonSSMFullAccess

  • Go to IAM -> Policies and in the fileter for “AmazonSSMFullAccess”


  • Mark the role and Form the policy actions chose AttachIAM2
  • Chose the user that you are usingIAM3.png

This will cover all the rights that will be nedded for the example.

Preparing the instance

As already mentioned the instnace should be running on one of the supported operating systems. For the test I will create an Amazon Linux instance. Additinaly 2 conditions have to be met:

  1. The instance has to be part of the created SSMManaged Role
  2. An SSM service has to be running

No I will create an Amazon linux instance with the SSMManaged Role.

  • Go to EC2->Instances and click on “Launch Instance”
  • Choose a Amazon Linux AMI – I took an older image1
  • Choose instance type – Any is ok but due to cost limitation I took t2.micro2
  • On the next screen choose SSMManaged Role3
  • The storage has no influance so click next4
  • Create and set a Name tag for example as “PatchTest”5
  • Chose a Security group that will allow ssh access to the instance6.png
  • Click “Review and Launch”7.png
  • Generate a ssh key that will allow you access to the instnance and Launch Instances8

Although I showed how to create the instance, already existing instance can be used as long it is running on supported operating system. To use such an instance it has to be assigned to the SSMManaged Role.

After the instance is launched install the SSM agent on the operating system. To do so login the the instance via ssh and execute folowing commands:

cd /tmp
sudo yum install -y
sudo status amazon-ssm-agent

The status command should show that amazon-ssm-agent is running.

Checking system compliance and patching the instance

To verify the patch complience a system scan has to be performed:

  • Go To EC2->Run Command and click “Run Command”1
  • Chose AWS-RunPatchBaseline and scrol down2.png
  • Chose the instance id and as operation Scan3.png
  • Click Run and verify the results4.png
  • Verif that the scan executed sucessfuly6.png
  • Now go to to “Patch Complience” To verify if there are any updates for the instance. It should show that the instance is missing updates. 7.png

When exploring the details, the non compliante packet will probably be the kernel package:


Now simalary to the scan operation a patching operation can be started:

  • Go To EC2->Run Command and click “Run Command”
  • Chose AWS-RunPatchBaseline and scrole down 1.png
  • Specify the instance and as operation choose Install2.png
  • Run the command ( This will reboot the instance ) and check if it was executed succesfuly4.png3.png

To verify if everything worked let’s check the Patch Compliance view:



SSM is a tool that among other things allows easily updates of instances based on Patch Baselines defined in AWS. After initial configuration the entire process is easy and quick. The Patch complience view in AWS console provides a quick overview of the entire enviroment. The entire system can be additionaly expanded with maintance windows, tag’s and custom configurations of Patch baselines allowing automatic patch appliance and monitoring of complex enviroments.

Tagged with:
Posted in AWS, Linux Administration

Importing SOA VM to Amazon Cloud – Part 1


Aldough Oracle is pushing it’s own cloud solutions agresivly there are still other cloud providers in the market that can be used to build similar functionality. Migration of existing infrastructure to the comercial cloud is a scenario worth considering. Today I will show how to use Amazon Cloud Services (AWS) to move an existing SOA suite VM to Amazon Elastic Compute Cloud (Amazon EC2). For this porpuose I will use a Oracle Pre-built Virtual Machine for SOA Suite 12.2.1 and import it to AWS. After the import I will create a running instance that can be used further deployment and development of integration solutions.

Read more ›

Tagged with: , , , ,
Posted in Linux Administration, Middleware

Listening address Change in Weblogic 12.2.1 with OWSM

Changing the listening port and address may be more complicated than just updating the settings in WebLogic Administration Console. The reason for this is the fact that Cross-Component Wiring for Auto-Discovery of Policy Manager is used.

“Wiring is simply a piece of configuration in one component that points to another component, such as a URL that points to the admin interface of a component. With cross-component wiring:

  • Service providers publish their endpoints to a Service Table. These endpoints can be published automatically, such as when you create or extend a domain using the Configuration Wizard, or can be published manually by the administrator.
  • Clients contain configuration that points to the service (for example, it has the service URL). The client is “bound” to the service by updating this configuration with the service information that was published to the Service Table. Binding is performed automatically when creating or extending a domain using the Configuration Wizard, or can be done manually by the administrator.

When you install and configure Fusion Middleware on WebLogic Server, the local service table is created. It provides a means for service providers to publish endpoint information about their services, and for clients of these services to query and bind to these services. The local service table is scoped to a domain, and contains services that are offered by that domain.”[1]

When updating the domains configuration via WebLogic Administration Console changes to Policy Manager URL are automatically published but the OWSM Agent Hook client is not automatically bound to the new URL.

This situation will cause issues with connecting to the policy manger. Let’s look at the following example how to change and update the configuration with the new addresses.

Task 1 – Updating The listening address

  • Open and login to WebLogic Administration Console as an administrator


  • Go to Environment->Servers->Configuration and click On the SOA managed server (or the server hosting OWSM policy manager )


  • Adjust the Listen address int the server Configuration->General tab and Afterwards click Save button


  • For the address change to take place a server restart is nessesary

Task 2 – Updating component Wiring

  • Login into Enterprise Manager


  • Go to Cross Component Wiring -> Components


  • In the OWSM Policy manager the connection addresses should be published. If they are not each one and click the publish button


  • Go to OWSM Agent chose “owsm-pm-connection-t3” (Notice that the status is Out of Sync) and click Bind10
  • In the Bind configuration dialog the address should be now correct. Leave the fileds as they are and Click on the Yes button.


  • Repeat the last 2 steps for all out of sync components
  • Restart All managed servers
  • As a check you can log in to EM and check if the components are Wired:



Tagged with: , , ,
Posted in Middleware