Patch policies do address Linux machines, part of what makes Automox so awesome from jump street!!

I have ours broken up into 3 (canary, and A&B groups) using the builtin update policy.

Linux definitely run on their own cycle, but to keep things level we run our updates monthly after MS Patch Tuesday. That way every OS is on the same cadence etc.

Thanks for the feedback.I'm trying to understand a little more about creating update policies and how they work.I read the material and checked at the automox university, but I still had some doubts.Could you guide me on how to create a specific update policy for Linux and how to monitor it?

Sure! I have some screenshots below that shows my canary group, you can adjust the sched to fit your needs, we have several Linux(and Windows for that matter) machines that we have as our test bed, cross prod, test and simple standalone servers, that way we can catch any issues!

You want to select the Create Policy link and use the Patch All option

Pretty straight forward here, as you can see I have my Canary:Servers tag on those servers in the Linux Server Group I want to catch everything, everywhere all at once lol!

Schedule here is every Mon,Wed,Fri at 7pm, being servers that is after hours and they can reboot if needed. I have other alerting of course if any updates cause an issue.

Also pretty straight forward here, being servers we dont need any notifications and we want to restart right away if needed! Click save and it will run at its next setup time! Server side are for sure the easiest to do, you know when you are out of production time, you dont need to warn its going to happen etc etc! 

As for monitoring the Policy Results Report is KING! You can scroll the activity log as well, but then you get everything thats happened during the time frame not just your updates. The Policy Results Page is broken down into each policy and is super helpful!

You can see my Canary ran 2 days ago, 2 needed a patch, 2 were scanned but patched and my other Linux didnt have the tag so were left out.

Clicking on the green Success results you see, how many and what they were. Here you can see 8 of the 10 just to save on screenshots lol. I didnt have any errors this run but if you had you can click on the red Fails and see what failed and the error codes. Here is a random Windows one with a failure.

We have and ZERO issues with the output being false or not telling use if there was an issue. I am in there most days looking at results etc, but if you are cooler than I you can use the API to makes calls and get those as well, I am slowing learning that side lol!

Over all super easy to setup and see your policy results right away.

Hope this helps a bit!! Let me know if you want me to break any part down a bit more!

Couldn’t have said it better myself ​@CallmePH .

Patch policies are the easiest way to set it and forget it, and also take advantage of the reporting (specifically pre-patch report---what is GOING to happen).

For more advanced situations, Worklets are possible to leverage for linux updates. Worklets would allow you to craft the exact update commands you want to run, whereas the patch policies will execute commands created by our engineering team, untouchable by the client.

Hello
No words to thank you.
Here I usually use the worklets to update.
when IVM-rapid7 points out some vulnerability I usually create the worklet and update through it, but it's a lot of work, so I wanted to understand a little more about the update policy.

Recently we had the "Apache Commons Text" note that should be updated, so I had to do it via Worklet

thank you very much, I will try to create the update policies

I am very happy to help and glad it was that helpful!!