Enhancing Linux Server Discovery Patterns: Capturing Patch Details for Better CI Management
Use Case:
In the realm of IT operations and server management, keeping a precise record of patch details is crucial. Recently, our patching and server teams identified a gap in our Linux Server Configuration Items (CIs)—specifically, the need to capture detailed information about patches, including descriptions and dates. Out-of-the-box (OOB) solutions didn't meet these needs, so we extended our Linux Server discovery pattern to address this challenge. Here’s a brief overview of how we tackled this problem and some insights into the process.
Prerequisites:
- Ensure that the following fields are present on the Linux Server Form:
- Patch Description
- Last Patch Date
- At least one identification section must succeed for the extensions to run.
- Click the Debug button and populate the IP address of a server to test with. If necessary, modify the MID server selection. Click Connect and wait for the identification and lower order extension sections to complete.
Steps to Extend the Discovery Pattern:
- Go to Pattern Designer - Discovery patterns in the navigator.
- Search for Linux Server and open.
- Click on the Add button in the extension section and type a descriptive name and click done.
- Click on the newly created extension to launch pattern designer.
- You should now be greeted by pattern designer and an untitled step.
- Click the Debug button and populate the IP address of a server to test with. If needed modify the mid server selection. Click connect and wait for the identification and lower order extension sections to run.
- Once debugging is complete, you should see CI Attributes populated and temporary variables from previous identification sections and extensions.
- Setting the Privileged Command: We initiated by defining the privileged command needed to execute on the Linux server. This command is used to gather necessary data. The command setup was as follows:
- Extracting Patch Details: To fetch the details of the latest patch, we executed the following command:
rpm -qa --last | awk '/kernel/ { print $1, $3, $4, $5; exit }'
- This command provides the patch name and date in a format like kernel-headers-2.6.32-755.35.1.e16.x86_64 20 Nov 2020.
- Processing and Storing Patch Information: The challenge was to parse the output and format it into a standardized date format (yyyy-mm-dd) for consistency in our records. I attempted to modify the command to directly produce the output in yyyy-mm-dd format, but it resulted in an error, although the command was functioning correctly on Linux.
Although my initial attempts with delimited text, eval() and preprocessing scripts did not yield the desired results, I found success using after business rule (BR) that handles both inserts and updates. This rule extracts the date, reformats it, and sets the u_last_patch_date field by initiating the Glide date.
- Sync the Linux Server pattern for the Mid-Severs and run a quick discovery to confirm if it is working.
Results and Insights:
The implemented solution efficiently updates the Linux Server CI with accurate patch information. The business rule ensures that both new entries and existing records are updated correctly whenever there’s a change in the patch description.
Alternative Approaches:
If anyone has suggestions for more streamlined or robust methods for parsing and formatting such data, I’d be eager to hear your insights. Exploring different techniques and tools can lead to more efficient solutions and better practices in server management.
Conclusion:
By extending our Linux Server discovery pattern, we’ve improved our patch management capabilities, offering our patching and server teams the precise information needed for better oversight and operational efficiency. Continuous improvement in these areas is essential for maintaining a robust IT infrastructure.
Feel free to connect and share your experiences or suggestions on enhancing server discovery and management processes!
Regards,
If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.
Thank you for your consideration.
Selva Arun
