Settings can be accessed via the button in the upper right corner of the Endpoints -> Readiness page.
Enable Endpoints Readiness
The Endpoint Readiness feature can be disabled/enabled.
If the Readiness is disabled, all exemptions will not appear and JetPatch won't inform the user about endpoint issues related to patching readiness.
Required Repository Configuration
JetPatch needs to know which repositories the environment is configurable for in order to make sure it is all set up as expected to ensure high security.
A new configurable repository must have:
- Name
- Endpoint specifications -
- Operating System - the OS that can work with the configured repository.
- CIDR list - Specify the endpoint needed to be configured to the configured repository using CIDR entry
- Repository specifications - List of enabled repository IDs. To fetch the repository ID from an endpoint:
- For Windows OS- The IP/Hostname of the WSUS appears in the endpoint configuration as specified in "Specify intranet Microsoft update service location". More information on EP configuration can be found in WSUS Configuration ("Endpoint server configuration" section)
-
For Linux OS -
- YUM based systems -"yum repolist -v" or "yum repolist all -v " (to see disabled repositories also). The value for the settings should be the same as the "Repo-id".
- ZYPPER based systems - "zypper repost". The value for the settings is under the "Alias" column.
- Note: You can also run the built-in endpoint readiness task to gather this information for Linux OS
For "Required Repository Configuration" examples check the Required Repository Configuration Examples.
-
By selecting an option for manual addition, the system will behave as it is now without any changes
-
The Add button will be disabled until an operating system is selected and all Repository fields are filled
-
When User Press ‘Add’ - The Repositories will be added to the List with Relevant Details (Same Behavior)
Add Repositories - Autocomplete
- Note: If you just enabled endpoint readiness for the first time, it may take 30 minutes before autocomplete starts working.
- By selecting an option for Autocomplete Addition :
- A New Search Field will be displayed
- Watermark - Enter endpoint name / IP
- The search will bring all matches Applicable Endpoints (Search - ‘Include’) & display them on a Table with the relevant information:
- Name
- IP
- Operating System
- Repositories
-
When the User Select Lines' The Repositories will be Auto-added to the Repositories list with
-
- ALL Relevant Details (Same Behavior)
Endpoint Repositories - Search Behaviors :
-
Able to search by name - Search type is ‘Include’
-
The table will be updated according to typed characters - Minimum 2 Characters
-
No Matches - Information Message will be displayed “No Endpoints found'
-
Delete Search Value - The endpoint repositories table will not be displayed
Linux Subscription
Readiness Checks Interval and Timeout
- Not-ready endpoints will check readiness criteria every (minute) - What is the frequency of readiness checks in not-ready endpoints
- Ready endpoints will check readiness criteria every (minute) - What is the frequency of readiness checks ready endpoints
- Timeout for readiness check operation is - Timeout for the readiness check operation.
Endpoint Communication with WSUS
- The last status reported for Windows Update Agent to WSUS should be less than (minutes) - If a Windows endpoint didn't communicate in the configured time, JetPatch will raise an exemption.
Note - The configured value for Endpoint Communication with WSUS should be higher than the Discovery Source WSUS scripts run frequency:
- discovery-source.WSUS.success.sleep-time.min (default 20)
- discovery-source.WSUS.error.sleep-time.min (default 20)
Required Repository Configuration Examples
Windows - Single WSUS
Environment details: A single (Main) WSUS in the environment
Required Repository Configuration Settings: A single entry that will apply to all environments, without CIDR limitation.
This can be achieved by filling the CIDR as 0.0.0.0/0. With this configuration, JetPatch will match any endpoint in the environment with the configured Repository in the entry
Windows - Multi-WSUS (Main-Replica architecture)
Environment details: A Main-Replica WSUS architecture in the environment. Usually, the Replica is configured for a remote site that has a special CIDR range.
Required Repository Configuration Settings:
- One entry pointing to the main WSUS without CIDR limitation - 0.0.0.0/0
- Another entry configured for the endpoint that communicates with the Replica with the required CIDR list
Notes:
- If an endpoint should communicate with the Replica WSUS but is configured for the Main WSUS - JetPatch won't detect it, it will be in a "ready" state.
- If an endpoint should communicate with the Main WSUS but is configured for the Replica WSUS (and it's not in the IP range of the CIDR) - JetPatch will detect it and will have the "unready" status.
Linux - Multi-OS & Several Environments
Environment details: Several Linux flavors in different sites.
For example - RHEL 8 & 7 in two sites (A & B):
- RHEL 8 in site A - should communicate with repositories A and B
- RHEL 7 in site A - should communicate with repository C
- RHEL 8 in site B - should communicate with repository D
- RHEL 7 in site B - should communicate with repository E
Required Repository Configuration Settings: Entry should exist to each Linux flavor in each site:
- OS - RHEL8, CIDR - site A, repositories A and B
- OS - RHEL7, CIDR - site A, repository C
- OS - RHEL8, CIDR - site B, repository D
- OS - RHEL7, CIDR - site B, repository E
Notes -
- If you add repoids with optional or extra, it will fail the Advisory ready check, because no advisories exist in either optional or extra repos (RHEL example). This is a known issue and will be fixed in a future version. For now, just remove those repos from endpoint readiness.
- If you don't have the exact CIDR block for any site you can put 0.0.0.0/0 but JetPatch will not detect situations when endpoints are communicating like they are located in a different site. For example - JetPatch will have a ready state for an RHEL8 EP from site B that is configured to work with repositories A and B (although it should communicate to repository D)
- JetPatch assumes that the repositories (A, B, C, D, and E) should be enabled. JetPatch ignores disabled repositories.
Related Articles
- Endpoint readiness overview
- Readiness criteria guide and troubleshooting
- What is the patching checklist?
- Running a task
Comments
0 comments
Please sign in to leave a comment.