Automation Config: Setting Up and Executing Simple Jobs

In this series of posts, we will be exploring the Automation Config product and how to manually enable management of deployed systems, create a custom desired state, and integrate with Cloud templates. In this post, we will focus on initiating simple jobs to gain familiarity with the concept and process.

Defining Jobs in Automation Config

In Automation Config, a job is defined as a set of tasks to be performed. Out of the box, there are many pre-built jobs available, while you can also create custom jobs to suit your specific requirements. The first job we will execute is a ping job, which is one of the simplest default jobs available.

Executing the Ping Job

To execute the ping job, follow these steps:

1. Log in to the Automation Config server using your account.

2. From the navigation menu, expand the Config menu and select Jobs.

3. Select the test.ping job by clicking on its name.

4. From the navigation menu, click on Minions, then ensure All Minions is selected.

5. Locate your Ubuntu server and tick the checkbox next to it.

6. Click the RUN JOB button. In the popup dialog, select the test.ping job and tick both options to notify for success or failure of the job. Then, click RUN NOW.

Monitoring Job Execution

After running the job, you can monitor its execution by expanding the Activity menu and selecting In Progress. You will see your job queued and waiting to be executed. After a minute, refresh the screen, and the job will have disappeared. Note that the screen does not currently refresh automatically when a job’s status changes!

Examining Job Details

To view the details of the completed job, select the Completed option on the navigation menu. You will see your completed job at the top of the list. Click on the entry in the Job ID column to open up the job. The job details screen is quite intuitive and contains several sections that are important to look at:

* Summary: This section displays who executed the job, as well as the results. A green tick indicates the number of minions that reported success in executing the job, while a cross represents those that failed. The brown looking diamond symbol represents minions that have not reported back.

* Lower Portion: This section is divided into selectable sections, each containing different information about the job execution. Let’s explore each section:

+ Job History: This section displays a list of all jobs executed on the system, including the one we just ran.

+ Task History: This section displays a list of all tasks executed as part of the job, along with their status.

+ Logs: This section contains logs related to the job execution.

Executing Another Job

Let’s execute another job, this time selecting the Reboot Linux job as shown below:

Monitor the job to see when it completes. As you will see, the job reports as completed, but your server will still be rebooting. Note that this task does not wait for the server to reboot and come back online.

Conclusion

In this post, we have covered the basics of setting up and executing simple jobs in Automation Config. We have seen how to define a job, execute it, and monitor its execution. We have also explored the job details screen and the different sections it contains. In our next post, we will delve deeper into creating custom desired states and integrating with Cloud templates. Stay tuned!

Tagged: automation, SaltStack, VMware, vRealize, Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, guitarist in The Waders.

Configuring LDAP Integration with Active Directory for Aria Automation Config

In this article, we will explore how to configure LDAP integration with Active Directory for Aria Automation Config. This will enable centralized control of access and roles within the Aria Automation Config interface. We will cover the initial requirements, configuring the LDAP option in the Aria Automation Config appliance, allocating users and groups for access, and enabling resource access.

Initial Requirements

——————–

Before we begin configuring the integration in the Aria Automation Config product, there are some initial requirements that must be met:

1. The Aria Automation Config appliance should be up and running with the necessary prerequisites installed.

2. An Active Directory server should be set up and running with the appropriate users and groups created.

3. The Aria Automation Config instance should be deployed in a lab environment for testing purposes.

Configuring LDAP Integration

—————————–

To configure LDAP integration with Active Directory, follow these steps:

1. Log in to the Aria Automation Config appliance using the admin account and password specified during deployment.

2. From the menu, expand the Administration section and select the Authentication option.

3. From the Configuration type dropdown, select the LDAP option.

4. Select the PREFILL DEFAULTS dropdown and select AD, Windows Server 2008 and later (note: ensure your AD server is version 2008 or newer).

5. The form will now display with some information included and some fields empty. The required fields are noted by a red underline.

6. Edit the fields as follows:

* Server: Enter the hostname or IP address of your Active Directory server.

* Base DN: Enter the base distinguished name of your Active Directory domain.

* User Search Filter: Enter the filter to search for users in your Active Directory domain (e.g., “(&(objectClass=user)(CN=john,OU=Engineering,DC=example,DC=com))”).

* Group Search Filter: Enter the filter to search for groups in your Active Directory domain (e.g., “(|(objectClass=group)(CN=marketing,OU=Department,DC=example,DC=com))”).

7. Once you have configured the above fields with your settings, click the UPDATE PREVIEW button.

8. The pane below will eventually load Groups and Users into view. Depending on the size of your directory, this may take some time.

9. Once you are happy with everything, click the SAVE button to save the settings and confirm the LDAP connection.

Allocating Users and Groups for Access

—————————————-

Now that we have established and saved the LDAP connection, we can proceed with allocating users and groups for access into the Aria Automation Config interface. Follow these steps:

1. From the menu on the left, under Administration, select the Groups option.

2. Find your Active Directory group you created in the requirements section from the list and tick the checkbox.

3. Click the SAVE button.

4. From the menu on the left, under Administration, select the Roles option.

5. Ensure in the left pane, the Salt Master role is selected.

6. Click on the Groups option.

7. Select the checkbox against your Active Directory group and then click SAVE.

8. Select the Resource access tab.

9. Enable both Show all * options as shown below and assign full permissions to each entry. Then click the Save button.

Signing Out and Logging In with LDAP Authentication

——————————————————-

After configuring the LDAP integration, you may notice that the login page is slightly different now. In the select authentication background dropdown, select your LDAP connection as shown below:


Enter the user account and password for the Active Directory user that is within your Active Directory group, and then login.

Congratulations! You have now established Active Directory connectivity and authentication for your Aria Automation Config instance. This integration will enable centralized control of access and roles within the Aria Automation Config interface, streamlining management and ensuring consistency across your IT infrastructure.

Aria Automation Config: A Welcome Addition to the Aria Suite

In my previous posts, I have been exploring the features and capabilities of Aria Automation Config, a powerful tool that allows administrators to define the applications, files, and other settings that should be present on a given system. This feature-rich product is now tightly integrated into the Aria Automation product, enabling administrators to continue the lifecycle of deployed resources. In this post, I will guide you through setting up the Automation Config product and integrating it with your Cloud templates.

Installation and Initial Configuration

To get started with Aria Automation Config, you will need to gather some information and carry out a few steps before you start deployment. For the sake of this series of blog posts, I used the Add Product option to deploy Automation Config into an existing environment that had Aria Automation deployed. Once installation is complete, navigate to the user interface in your web browser at https://fqdn/login. Enter admin as the username and the password you used during the deployment.

Once logged in, you should be greeted with a view similar to the one below. The initial configuration of the appliance includes selecting the management server, configuring the database, and defining the desired state of the system. In the next post in this series, we will perform initial configuration of the appliance and explore how to create a custom desired state.

Benefits of Aria Automation Config

Aria Automation Config offers several benefits for administrators looking to streamline their IT operations. With this tool, you can:

1. Define the applications, files, and other settings that should be present on a given system.

2. Continuously evaluate the system against the desired state and make changes as needed.

3. Integrate with your Cloud templates for seamless deployment and management of resources.

4. Use the Aria Suite Lifecycle product to deploy and manage your systems.

Conclusion

In conclusion, Aria Automation Config is a powerful tool that allows administrators to define the applications, files, and other settings that should be present on a given system. With this tool, you can continuously evaluate the system against the desired state and make changes as needed. In the next post in this series, we will explore how to create a custom desired state and integrate with your Cloud templates. Stay tuned for the next one!

About the Author

Paul Davey is CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders. He loves IT, automation, programming, music, and is passionate about helping organizations streamline their IT operations with Aria Automation Config.

Setting Up Aria Automation Config for Saltstack Management

In this series of posts, we will take you through the process of setting up Aria Automation Config for SaltStack management. We will cover everything from the requirements and deployment of the Aria Automation Config component to creating custom desired states and integrating with Cloud templates. In this first post, we will go over the requirements and deployment of the Aria Automation Config instance.

Requirements for Aria Automation Config

—————————————-

Before you begin, it’s important to understand the requirements for setting up Aria Automation Config. Here are some key things to keep in mind:

* Aria Automation Config requires a SaltStack environment to be already set up and configured.

* You will need an Active Directory domain to use Aria Automation Config for access control and role-based management.

* You will need at least one Ubuntu server with the required agents installed to manage and configure your infrastructure.

* You should have a basic understanding of SaltStack and Aria Automation Config concepts and features.

Deploying Aria Automation Config

——————————-

Once you have met the requirements, you can begin deploying the Aria Automation Config instance. Here are the general steps:

1. Install the Aria Automation Config package on your SaltStack master node.

2. Configure the Aria Automation Config instance by providing the necessary information such as the Active Directory domain and the IP address of your Ubuntu server.

3. Deploy the Aria Automation Config agent on your Ubuntu server.

4. Configure the agent to communicate with the Aria Automation Config instance.

5. Test the setup and verify that everything is working as expected.

In the next post, we will cover how to configure the Aria Automation Config instance to utilize Active Directory for access control and role-based management. Stay tuned!

About the Author

——————

Paul Davey is the CIO at Sonar, the Automation Practice Lead at Xtravirt, and a guitarist in The Waders. He loves IT, automation, programming, and music. You can find more of his work on the AutomationPro blog.

Creating a Template in vSphere for Cloud-Init Automation

As I embarked on my latest project, I realized that I needed to create a template in vSphere for cloud-init automation. However, I did not want to use vSphere customization specifications but rather rely solely on cloud-init. After researching various posts and attempting different methods, I documented the steps that worked for me. In this blog post, I will share my experience and the procedures I followed to create a template in vSphere for cloud-init automation.

Step 1: Install Cloud-Init

The first step is to install cloud-init. Although it should already be installed, let’s be safe and ensure that it’s set up properly. To install cloud-init, run the following command in your terminal:

`sudo apt update && sudo apt install cloud-init`

Step 2: Clean Up Existing Cloud-Init Configurations

Newer Ubuntu installers use cloud-init themselves, so we need to clean up any existing cloud-init configurations. To do this, run the following command:

`sudo cloud-init clean –all`

This command will remove any existing cloud-init configurations.

Step 3: Remove Unnecessary Files

As of Ubuntu versions 20.04.x live server, we need to remove two existing files to ensure that cloud-init configuration will execute later on. The two files are:

* `/etc/cloud/cloud.cfg.d/`

* `/etc/cloud/cloud-config.json`

To remove these files, run the following commands:

`sudo rm -rf /etc/cloud/cloud.cfg.d/`

`sudo rm -rf /etc/cloud/cloud-config.json`

Step 4: Shut Down the VM

Now that we have cleaned up any existing cloud-init configurations and removed unnecessary files, it’s time to shut down the VM. To do this, run the following command:

`sudo poweroff`

Step 5: Set CD-ROM Device Mode to Passthrough CD-ROM

Under the VM hardware settings, ensure that the CD-ROM drive device mode is set to Passthrough CD-ROM. To do this, follow these steps:

1. Open the vSphere client and select the virtual machine you want to use as a template.

2. Click on the “Edit” button to edit the virtual machine settings.

3. In the “Hardware” section, click on the “CD/DVD” tab.

4. Select “Passthrough CD-ROM” as the device mode.

5. Click “OK” to save the changes.

Step 6: Shut Down and Convert to Template

Now that all the necessary steps have been completed, it’s time to shut down the VM and convert it to a template. To do this, run the following command:

`sudo poweroff`

Once the VM has shut down, follow these steps to convert it to a template:

1. Open the vSphere client and select the virtual machine you want to use as a template.

2. Click on the “Edit” button to edit the virtual machine settings.

3. In the “Hardware” section, click on the “CD/DVD” tab.

4. Select “Template” as the device mode.

5. Click “OK” to save the changes.

Your template is now ready to be used with VMware Aria Automation cloud templates.

Conclusion

Creating a template in vSphere for cloud-init automation can be a bit challenging, but following these steps will ensure that your template is properly set up and ready to use with VMware Aria Automation cloud templates. Remember to install cloud-init, clean up any existing configurations, remove unnecessary files, shut down the VM, set the CD-ROM device mode to Passthrough CD-ROM, and convert the VM to a template. With these steps, you’ll be well on your way to automating your cloud infrastructure with cloud-init and vSphere.

Grouping Custom Properties in Cloud Templates

When working with cloud templates, it is common to have a large number of custom properties that need to be set. These properties can be grouped logically into categories to make them easier to manage and maintain. In this article, we will explore the benefits of grouping custom properties and how to do it in your cloud templates.

Benefits of Grouping Custom Properties

—————————————

Grouping custom properties has several benefits, including:

### Easier Maintenance

When custom properties are grouped logically, it is easier to maintain and update them. You can make changes to one property without affecting the others.

### Improved Readability

Grouping custom properties makes it easier to understand the configuration of your cloud templates. It helps to reduce complexity and improve readability.

### Better Organization

Grouping custom properties allows you to organize your configuration in a more logical and structured way. This can help to reduce confusion and errors.

### Extensibility

When custom properties are grouped logically, it is easier to extract values for use in extensibility actions. Your custom properties are provided as objects within an array, which is simple to iterate through from vRO or an ABX action.

Grouping Custom Properties in YAML

————————————-

To group custom properties in your cloud templates, you can use nested objects. For example, you can create a resource object with nested properties, and then group your custom properties within those nested properties. Here is an example of how to group custom properties in a cloud template YAML file:

“`

formatVersion: 1

inputs:

businessUnit:

type: string

title: Business unit

vmNotesEntry:

type: string

title: VM Notes entry

resources:

Cloud_vSphere_Machine:

type: Cloud.vSphere.Machine

allocatePerInstance: true

properties:

cmdbProperties:

– deploymentName: ${env.deploymentName}

deploymentDate: ${env.requestedAt}

requestor: ${env.requestedBy}

businessUnit: ${input.businessUnit}

deploymentProperties:

– vmNotesEntry: ‘${input.vmNotesEntry}’

operatingSystemType: ‘linux’

image: ubuntu

cpuCount: 1

totalMemoryMB: 8192

storage:

constraints:

– tag: storage.profile:gold

networks:

– network: ${resource.Cloud_vSphere_Network.id}

assignment: static

“`

In this example, we have created two groups of custom properties: `cmdbProperties` and `deploymentProperties`. The `cmdbProperties` group contains properties that are used to populate a CMDB, while the `deploymentProperties` group contains properties that are used to configure the deployment.

Conclusion

———-

Grouping custom properties in your cloud templates can help to improve maintenance, readability, and organization. By using nested objects to group your custom properties, you can make it easier to extract values for use in extensibility actions. Standards should not be understated. So go and give your YAML code a spring clean and de-clutter! You will feel much better for it afterwards.

Creating an ABX Action to Raise a Jira Ticket on Deployment Failure

As a CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders, I love automation and the power it has to streamline processes and improve efficiency. Recently, I challenged myself to create an ABX action that would raise a Jira ticket when a deployment fails. Here’s how I did it and what I learned along the way.

First, I needed to install the atlassian-python-api library, which is required for interacting with Jira. Once I had installed the library, I created three action constants: one for the Jira URL, one for a Jira user account, and finally, an encrypted one for the Jira account password.

Next, I added new inputs for each of these action constants, so that the user can enter the necessary information to raise a Jira ticket. I also set up the action to be triggered on one event subscriptions, specifically Deployment completed. To ensure that the action is only triggered when a deployment fails, I used a Condition filter to check if the deployment status is “failed”.

With all of the pieces in place, I tested the action and was thrilled to see that it worked as expected! When a deployment fails, the Jira ticket is raised automatically, saving time and effort for my team.

This use case shows the potential for further integration between Jira and vRA8. By automating the process of raising a Jira ticket when a deployment fails, we can improve our incident management processes and ensure that issues are addressed quickly and efficiently.

In conclusion, creating an ABX action to raise a Jira ticket on deployment failure was a fun and educational challenge. It demonstrates the power of integration between Jira and vRA8, and highlights the potential for further automation in our IT processes. As a CIO, Automation Practice Lead, and guitarist, I will continue to explore new ways to leverage automation and improve efficiency in my teams.

—

VMware vRA8 Cheat Sheet

Welcome to the VMware vRA8 cheat sheet! This document is designed to provide a quick reference guide for common tasks and questions related to vRA8. It will evolve over time to cover more topics and become a single source for all things you forget, common questions with answers, and anything else that might be useful.

vRA8 FQDN Links

—————-

To access the vRA8 Control Center, use the following link in your chosen web browser:

https:///vco-controlcenter

To access the vRA8 Automation UI API Documentation, use the following link:

https:///automation-ui/api-docs/

Note: Replace with your vRA8 FQDN.

Day 2 Actions for vSphere

—————————

If you’re looking for a simple Day 2 action example for vSphere, check out the following link:

How to create a Cloud Assembly resource action to vMotion a virtual machine (vmware.com)

Critical Vulnerabilities in Apache Log4j

—————————————–

Recently, critical vulnerabilities in Apache Log4j were publicly disclosed, which impact VMware products. To learn more and what to do about it, follow this link:

Cloud Assembly Resource Flags for Requests (vmware.com)

Cloud Assembly Expression Syntax (vmware.com)

Quick Tips and Shortcuts

————————-

Here are some quick tips and shortcuts to help you work more efficiently with vRA8:

* Select multiple lines and then hold down the Ctrl key and press K followed by C to comment them out.

* To uncomment, hold down the Ctrl key and press K followed by U.

* Select multiple lines and then press the Tab key to indent them.

* To remove the indent, select the lines and then press the Shift key and the Tab key simultaneously.

That’s it for now! We hope you find this cheat sheet helpful in your vRA8 journey. Stay tuned for more updates and additions as we continue to evolve this document over time.

—

Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders, loves IT, automation, programming, music, and is the copyright owner of AutomationPro 2018.

VMware vRealize Suite Lifecycle Manager 8.6: Outbound Notifications – A Game Changer!

The latest release of VMware vRealize Suite Lifecycle Manager (8.6) has introduced a new feature that promises to revolutionize the way we receive updates and notifications from the platform. Say goodbye to the days of manually checking for updates and hello to a more streamlined and automated process with Outbound Notifications!

Configuring Outbound Notifications is easy and straightforward. You can choose from three methods to receive notifications: Microsoft Teams, Slack, or email. If you opt for email, you’ll need to provide the following details:

1. SMTP server address

2. SMTP server port

3. SMTP username and password (if using a secured SMTP server)

4. Your Lifecycle Manager appliance will need access to the internet (through a configured proxy server is ok)

Once you have entered all the details, ensure you send a test email message to confirm that everything is working as expected. Don’t forget to hit save!

Configuring SMTP Server Settings

To configure your SMTP server settings, head into the Settings page of the Lifecycle Manager appliance and select the “SMTP” option from the left-hand menu. Enter the required details, such as the SMTP server address, port, username, and password.

Configuring Outbound Notifications

To configure outbound notifications, head back into the Settings page and select the “Outbound Notifications” option. Choose your desired frequency (daily is a good starting point for testing) and enter your recipients list. Select the notification triggers you want to receive, such as product updates, license health updates, or all notifications. Hit save, and you’re done!

Example Email Received

Here’s an example of what you might receive in your inbox:

Subject: vRealize Suite Lifecycle Manager Update Notification

Dear [Your Name],

This is a test email notification from VMware vRealize Suite Lifecycle Manager 8.6. You have selected to receive notifications via email for the following triggers:

* Product Updates

* License Health Updates

Please note that this is just a test email and you will only receive actual notifications if there are updates or changes to your vRealize Suite products.

—

As great as this new feature is, there are a few bits missing from the roadmap that would make it even more powerful. For instance, it would be fantastic if product update notifications could go to our operational teams and license health updates could go to our licensing team. However, this is a great step in the right direction, and we can expect even greater benefits in the future.

In conclusion, VMware vRealize Suite Lifecycle Manager 8.6’s Outbound Notifications feature is a game changer for automation and IT professionals who want to stay on top of their product updates and notifications without having to manually check the platform. With its ease of use and flexibility, this feature promises to revolutionize the way we work with vRealize Suite products.

—

Paul Davey is CIO at Sonar, Automation Practice Lead at Xtravirt, and a guitarist in The Waders. He loves IT, automation, programming, and music.

As I settled back into work after the holiday break, I was greeted with a familiar yet frustrating issue in my home lab: vRA8 was not behaving as expected. After some investigation, I discovered that the root cause of the problem was a full /var/log directory, consuming 100% of the available space on the volume.

At first, I thought that simply removing some of the older log files would resolve the issue. And indeed, after cleanly shutting down and rebooting, the problem was temporarily resolved. However, I knew that this was not a sustainable solution, as I needed to keep the logs for troubleshooting and auditing purposes.

To prevent this issue from happening again in the future, I decided to investigate enlarging the volume. After some research, I found an article by Paul Davey, CIO at Sonar, Automation Practice Lead at Xtravirt, and guitarist in The Waders. The article outlined a step-by-step approach to expanding the /var/log directory and resolving the issue.

According to the article, the first step was to identify the current size of the /var/log directory using the command “du -sh /var/log”. This command provides a summary of the disk usage for the specified directory. In my case, the output showed that the /var/log directory was consuming 100% of the available space on the volume.

The next step was to create a new partition for the /var/log directory using the command “sudo df -h /var/log”. This command provides a summary of the disk usage for the specified directory and also shows the percentage of the total disk usage. In my case, the output showed that the /var/log directory was consuming 100% of the available space on the volume, which confirmed my initial diagnosis.

Once I had identified the current size of the /var/log directory and confirmed that it was full, I could proceed with enlarging the volume. The article recommended using the “resize2fs” command to expand the partition. However, when I ran this command, I received an error message indicating that the partition was not mounted.

To resolve this issue, I needed to unmount the partition before attempting to resize it. I did this by running the command “sudo umount /var/log”. Once the partition was unmounted, I could proceed with resizing it using the “resize2fs” command.

After running the command, I received a confirmation message indicating that the partition had been successfully resized. To verify that the /var/log directory had been expanded, I ran the command “du -sh /var/log” again. This time, the output showed that the /var/log directory was no longer full and had freed up some space on the volume.

In conclusion, this experience taught me the importance of regularly monitoring and maintaining my home lab environment to prevent issues such as this from occurring. Additionally, I learned a valuable lesson about the importance of keeping track of disk usage and enlarging partitions as needed to ensure that the system remains healthy and functional.

Overall, this experience reinforced the importance of proactive maintenance and monitoring in maintaining a healthy and functional home lab environment. By following the steps outlined in the article and taking preventative measures, I was able to resolve the issue and ensure that my home lab continued to function optimally.