{"id":20316,"date":"2026-08-04T11:52:36","date_gmt":"2026-08-04T09:52:36","guid":{"rendered":"https:\/\/webhosting.de\/kernel-livepatching-unter-ubuntu-canonical-livepatch-sicherheit-server\/"},"modified":"2026-08-04T11:52:36","modified_gmt":"2026-08-04T09:52:36","slug":"kernel-live-patching-on-ubuntu-canonical-livepatch-security-server","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/kernel-livepatching-unter-ubuntu-canonical-livepatch-sicherheit-server\/","title":{"rendered":"Kernel Live Patching on Ubuntu: A Comparison of Canonical Livepatch"},"content":{"rendered":"<p><strong>Canonical Livepatch<\/strong> addresses critical kernel vulnerabilities <strong>Ubuntu LTS<\/strong> during normal operation and defers reboots to scheduled maintenance windows. In this post, I\u2019ll clearly explain how kernel live patching works on Ubuntu, where Canonical Livepatch excels, and how it stacks up in a direct comparison with alternatives.<\/p>\n\n<h2>Key points<\/h2>\n<ul>\n  <li><strong>Real-Time Patches<\/strong> Without a reboot for critical kernel CVEs<\/li>\n  <li><strong>Ubuntu LTS<\/strong>-Focus with integration into Ubuntu Pro<\/li>\n  <li><strong>Limited<\/strong> Maintenance Windows by Kernel Version<\/li>\n  <li><strong>None<\/strong> Userspace Live Patching<\/li>\n  <li><strong>Comparison<\/strong> About Ksplice, kpatch, kgraft<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/kernel-livepatching-ubuntu-9147.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Why Live Patching Matters on Ubuntu<\/h2>\n\n<p>I patch kernel vulnerabilities with <strong>Live patching<\/strong> immediately, rather than waiting for the next maintenance window. This reduces the <strong>Exploit Window<\/strong>, in which a known vulnerability is still active. Unnecessary reboots are eliminated, services remain accessible, and SLA targets can be met more reliably. Production servers, databases, and container hosts in particular benefit, because a reboot often triggers a chain reaction. For me, one thing is clear: reboot-free security fixes save time, reduce risk, and keep the focus on operations rather than firefighting.<\/p>\n\n<h2>How Canonical Livepatch Works Technically<\/h2>\n\n<p>Canonical Livepatch downloads binaries <strong>Patch Modules<\/strong> into the running kernel and selectively replaces faulty functions. A local service builds the <strong>Connection<\/strong> It connects to the Livepatch servers, checks for updates, and downloads signed modules. The kernel itself does not change its major version; instead, it receives precise fixes at defined locations. In my day-to-day work, I see that this approach maintains stability because it only modifies the necessary parts. Problem areas are addressed while workloads continue to run uninterrupted, and no application goes down due to a reboot.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/livepatch_vergleich_8234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Supported Ubuntu Versions and Kernels<\/h2>\n\n<p>I use Livepatch on <strong>LTS Versions<\/strong> such as April 18, April 20, April 22, and April 24, with official kernel variants such as generic, lowlatency, or cloud-specific derivatives. What remains important is the <strong>Cover<\/strong>: Canonical typically provides patches for a kernel version only for a limited period of time, usually around nine to thirteen months after release. After that, I plan a regular kernel upgrade and a reboot to receive further live patches. This applies to x86_64 and ARM64, provided the kernel comes from Canonical\u2019s sources. This guide helps me get a good overview of lifecycles: <a href=\"https:\/\/webhosting.de\/en\/kernel-versions-hosting-lts-mainline-kernel\/\">Kernel Versions and LTS<\/a>.<\/p>\n\n<h2>Enabling Livepatch: Step by Step<\/h2>\n\n<p>I'll take care of the setup with <strong>Snap<\/strong> and an Ubuntu Pro token in just a few minutes. First, I check to see if snapd is running, then I install the package and start the service using my <strong>Token<\/strong>. To ensure reproducible workflows, I document the commands and store them in the configuration management system. Status monitoring is part of my monitoring process, so I can see patches and connections at any time. Anyone who wants to learn more about the concept in general can find background information on <a href=\"https:\/\/webhosting.de\/en\/kernelcare-patching-the-linux-kernel-without-a-reboot-hostingflow\/\">Patching the Kernel Without Rebooting<\/a> helpful.<\/p>\n\n<pre><code>sudo snap install canonical-livepatch\nsudo canonical-livepatch enable \nsudo canonical-livepatch status --verbose\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/kernel-livepatch-comparison-9647.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limitations and Scope of Canonical Livepatch<\/h2>\n\n<p>I keep the <strong>Boundaries<\/strong> Key point: Livepatch deals exclusively with the kernel, not with user-space packages like OpenSSL or glibc. Custom-compiled kernels, exotic builds, or unsupported variants are excluded, which is why I use official sources. In addition, the service focuses on critical and high-severity CVEs, while lower-severity issues are typically addressed via updates and reboots. Each kernel version has a specific time window; after that, a regular upgrade is required to stay up to date. In practice, Canonical Livepatch often covers only a portion of Ubuntu\u2019s CVEs via Livepatch\u2014frequently in the range of about five to ten percent\u2014which I factor into my security planning.<\/p>\n\n<h2>Canonical Livepatch Compared to Alternatives<\/h2>\n\n<p>I evaluate alternatives based on <strong>Cover<\/strong>, distribution support, rollback, and potential userspace patching. Vendors such as Ksplice, kpatch, or kgraft often promise broader support and, in some cases, live patches for medium-severity vulnerabilities. Some solutions offer a direct rollback without a reboot, which can save time in the event of incompatibilities. For environments running only Ubuntu LTS, Canonical Livepatch remains an attractive option because its integration, support cycles, and usability are well-aligned. Those running multiple distributions should take a look at this <a href=\"https:\/\/webhosting.de\/en\/live-kernel-patching-kernelcare-ksplice-kpatch-kgraft-secure\/\">Live Kernel Patching Overview<\/a> and clearly outlines the requirements.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Criterion<\/strong><\/th>\n      <th><strong>Canonical Livepatch<\/strong><\/th>\n      <th><strong>Alternatives<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Distribution Support<\/td>\n      <td>Focus on Ubuntu LTS<\/td>\n      <td>Often multiple distributions<\/td>\n    <\/tr>\n    <tr>\n      <td>CVE Coverage<\/td>\n      <td>Critical\/High, subset of gaps<\/td>\n      <td>Partly wide, including medium-sized steps<\/td>\n    <\/tr>\n    <tr>\n      <td>Userspace Patching<\/td>\n      <td>Kernel Only<\/td>\n      <td>Some also cover userspace<\/td>\n    <\/tr>\n    <tr>\n      <td>Rollback<\/td>\n      <td>Usually by changing the kernel and rebooting<\/td>\n      <td>In some cases, this can be done without a reboot<\/td>\n    <\/tr>\n    <tr>\n      <td>Integration<\/td>\n      <td>Close to Ubuntu Pro and Snap<\/td>\n      <td>Proprietary agents\/repos<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/KernelLivepatchVergleichOffice_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Best Practices for Production Use<\/h2>\n\n<p>I combine <strong>Livepatch<\/strong> I perform scheduled kernel upgrades and documented reboots to ensure coverage doesn\u2019t expire. I integrate status checks into my monitoring system and set up alerts for connection issues or missing patches. Change management remains mandatory: I schedule time windows, test on the staging environment, and then roll out to production in a controlled manner. For userspace updates, I maintain a clear patch plan and rely on fast, traceable rollbacks. Backups, hardening, and logging round out the security strategy so that no single component is left on its own.<\/p>\n\n<h2>Security Model and Chain of Trust<\/h2>\n<p>I trust Livepatch because the <strong>Chain of trust<\/strong> remains closed from build to delivery. Patches are signed by Canonical; the client verifies the signatures and loads only those modules that match the kernel version and architecture. The kernel applies changes via the <strong>upstream Livepatch subsystem<\/strong> To: Critical functions are atomically redirected upon entry, ensuring that no thread ends up in a half-finished state. Check before switching <em>Consistency Checks<\/em>, whether the current code path can be patched safely. If a check fails, the patch is not applied and the status reflects this\u2014which, for me, serves as an important safety net against unstable intermediate states.<\/p>\n<p>From an operations perspective, this means: I keep my systems up and running <strong>Supported kernel versions<\/strong>, enable Secure Boot only with valid signatures and prevent local tampering with the Livepatch directory. The service runs with system privileges; therefore, I restrict access and log viewing according to the <strong>Need-to-know<\/strong>-Follow the principle and document approvals in the Change Board.<\/p>\n\n<h2>Performance Overhead and Stability in Practice<\/h2>\n<p>In my daily use, I've noticed <strong>negligible overhead<\/strong>. The additional indirection jump in patched functions is generally not measurable and goes unnoticed even in latency-sensitive workloads. What I find more critical is the <strong>Patch Quality<\/strong>: Small, targeted fixes minimize risk. That\u2019s why I also use staging hosts, where I monitor new Livepatch versions under realistic workloads for a few hours to several days. If any irregularities occur, I document them, pause the rollout, and, if necessary, schedule an accelerated kernel upgrade with a reboot.<\/p>\n<p>Important: Livepatch is not a substitute for <strong>Feature Updates<\/strong>. Whenever kernel features, ABI changes, or driver updates are required, there\u2019s no way around the standard update followed by a reboot. I set aside specific time slots and contingency capacity for this.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/kernel_livepatching_vergleich_9823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Operation in Kubernetes, OpenStack, and container hosts<\/h2>\n<p>On Kubernetes and OpenStack nodes, Livepatch applies updates directly to <strong>Availability<\/strong> In clusters, I avoid brownouts by applying critical fixes without rebooting the nodes. My process: Livepatch keeps the nodes running safely, and I roll out regular kernel upgrades <strong>bundled<\/strong> during maintenance windows. Before scheduled reboots, I drain workloads in an orderly manner and ensure a clean fallback path is available.<\/p>\n<pre><code># Prepare Kubernetes nodes for reboot\nkubectl drain  --ignore-daemonsets --delete-emptydir-data --grace-period=60\n# Resume operations after reboot and checks\nkubectl uncordon\n<\/code><\/pre>\n<p>On container hosts (Docker\/Containerd), I estimate that running containers <strong>untouched<\/strong> will remain in place as long as only kernel functions are corrected. For particularly sensitive tenants, I also recommend a <em>Canary Host<\/em>-Pattern ready: First, a single host receives the new Livepatch update; only then does the rest of the group follow.<\/p>\n\n<h2>Automation and Mass Rollout<\/h2>\n<p>For larger fleets, I automate the activation process. In addition to Snap, I sometimes use the Ubuntu Pro client if it\u2019s already in use. I document both methods and ensure they\u2019re reproducible.<\/p>\n<pre><code># Option A: Snap Client\nsudo snap install canonical-livepatch\nsudo canonical-livepatch enable \n\n# Option B: Ubuntu Pro Client\nsudo pro attach \nsudo pro enable livepatch\npro status\n<\/code><\/pre>\n<p>For cloud instances, I use <strong>cloud-init<\/strong>, so that systems are mounted correctly right at boot time:<\/p>\n<pre><code>#cloud-config\npackages:\n  - snapd\nruncmd:\n  - snap install canonical-livepatch\n  - canonical-livepatch enable \n  - canonical-livepatch status --verbose || true\n<\/code><\/pre>\n<p>Configuration management (e.g., Ansible, Puppet) helps me with <strong>Idempotence<\/strong>: I define tokens, service statuses, and monitoring hooks in code. This ensures that Livepatch remains consistent across rebuilds, and any discrepancies are immediately flagged in the drift report.<\/p>\n\n<h2>Network, Proxy, and Restricted Environments<\/h2>\n<p>For Livepatch to work, the service needs <strong>Outgoing HTTPS traffic<\/strong>. On regulated networks, I route the connection through a corporate proxy. I can configure Snap itself centrally for this; the Livepatch service either inherits the settings or uses environment variables. Here's how I do it:<\/p>\n<pre><code># Set a system-wide proxy for Snap\nsudo snap set system proxy.http=http:\/\/proxy.local:3128\nsudo snap set system proxy.https=http:\/\/proxy.local:3128\n\n# Check service logs to verify that retrieval is working\njournalctl -u snap.canonical-livepatch.canonical-livepatchd -n 100 --no-pager\n<\/code><\/pre>\n<p>Air-gapped environments with no external access whatsoever are suitable for Livepatch <strong>difficult<\/strong>, since the modules need to be reloaded regularly. In such cases, I plan to implement stricter <strong>Maintenance cycles<\/strong> Implement proactive kernel upgrades and maintain a rigorous vulnerability scanning process to quickly patch known vulnerabilities with a reboot.<\/p>\n\n<h2>Fault diagnosis and troubleshooting<\/h2>\n<p>In my work, I encounter recurring types of errors that I address in a systematic manner:<\/p>\n<ul>\n  <li><strong>\u201cKernel not supported\u201d<\/strong>: The kernel variant or version is no longer supported. I plan to upgrade to a supported version and restart the system.<\/li>\n  <li><strong>\u201cToken invalid\/expired\u201d<\/strong>: I'll check whether the Ubuntu Pro token is still valid, renew it, and restart the service.<\/li>\n  <li><strong>Connection Problems<\/strong>: Test the DNS\/proxy and firewall rules. Then review the service logs and trigger a manual refresh.<\/li>\n  <li><strong>Patch not applied<\/strong>: I check whether the patch is available for my exact kernel build number and whether consistency checks are causing a block. If in doubt, I wait for a follow-up update or plan a kernel upgrade.<\/li>\n<\/ul>\n<pre><code># Check service status and recent activity\nsudo canonical-livepatch status --verbose\nsudo canonical-livepatch refresh\nsystemctl status snap.canonical-livepatch.canonical-livepatchd.service\njournalctl -u snap.canonical-livepatch.canonical-livepatchd -S -1h\n<\/code><\/pre>\n<p>For audits, I regularly check the status:<\/p>\n<pre><code>sudo canonical-livepatch status --verbose | sudo tee -a \/var\/log\/livepatch\/status.log\n<\/code><\/pre>\n\n<h2>Decision Guide: When a Live Patch Is Enough\u2014and When a Reboot Is Required<\/h2>\n<p>I see Livepatch as <strong>Safety Accelerator<\/strong> for critical kernel vulnerabilities that arise between two regular upgrades. Reboots are required when:<\/p>\n<ul>\n  <li>a fix <strong>ABI\/Structural Changes<\/strong> requires, which Livepatch cannot support,<\/li>\n  <li>Driver, <strong>Hardware Support<\/strong> or new kernel features are needed,<\/li>\n  <li>a security vulnerability <strong>widely applicable<\/strong> and since a live patch isn't available anytime soon for my kernel version,<\/li>\n  <li>Stability issues may occur that can be resolved by performing a regular kernel update.<\/li>\n<\/ul>\n<p>My approach remains pragmatic: Livepatch <strong>immediately<\/strong> Click to close the exploit window; at the same time, a <strong>orderly reboot<\/strong> plan for when feature updates or an expired maintenance window are coming up. That's how I balance availability and security without resorting to knee-jerk reactions.<\/p>\n\n<h2>Monitoring, Reporting, and Governance<\/h2>\n\n<p>I check the Livepatch status using <strong>canonical-livepatch<\/strong> and store results centrally for audits. Comparing them with CVE feeds and change logs shows me whether systems are responding as expected. For larger fleets, I use configuration management and secure policies to ensure that tokens, snap updates, and kernel sources remain consistent. Alerts for missing patches or expired maintenance windows help plan a reboot window in a timely manner. This allows teams to maintain an overview, reduce ticket volume, and transparently document security progress.<\/p>\n\n<h2>Assess the Cost Model and Licensing<\/h2>\n\n<p>A limited number of [...], for personal use, are available <strong>Systems<\/strong> It's available at no additional cost, which simplifies testing and setting up home labs. In corporate environments, Livepatch is part of Ubuntu Pro, which I subscribe to based on fleet size and requirements. I plan my budget in <strong>Euro<\/strong> and also take into account internal costs for operations, monitoring, and compliance. Savings result from reduced downtime, less night work, and fewer planning resources required for restarts. I make this decision based on operational risk, service windows, and the coverage required across multiple distributions.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/ubuntu-livepatch-vergleich-9482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hosting and Cloud Best Practices: Minimal Downtime, Greater Availability<\/h2>\n\n<p>On hosts with many <strong>VMs<\/strong> or containers, Livepatch helps bundle reboots and maintain high tenant availability. A single kernel restart can affect dozens of services, which is why I prefer to apply patches during normal operation. This makes it easier to manage SLA requirements, nightly deployments, and windows for extensive upgrades. Even on edge or remote systems, I save on travel time and avoid manual intervention. The effect is noticeable: fewer interruptions, more predictable maintenance, and a smoother operational window for critical systems.<\/p>\n\n<h2>Brief Summary: Using Canonical Livepatch Strategically<\/h2>\n\n<p>I set <strong>Canonical<\/strong> I use Livepatch where availability is critical and reboots can be scheduled. The service promptly patches critical kernel vulnerabilities, keeps services online, and effectively complements my update process. I deliberately factor in limitations such as the kernel focus, time windows per version, and partial coverage of CVEs. In homogeneous Ubuntu LTS environments, I\u2019m impressed by the tight integration, while multi-distro setups benefit from broader Livepatch portfolios. Those who maintain clear maintenance plans and take monitoring seriously will get the most out of Livepatch. <strong>Benefit<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Discover how Canonical Livepatch enables live kernel patching on Ubuntu LTS, closes critical security vulnerabilities without requiring a reboot, and keeps the Ubuntu kernel secure.<\/p>","protected":false},"author":1,"featured_media":20309,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[922],"tags":[],"class_list":["post-20316","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technologie"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"71","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Canonical Livepatch","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20309","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20316","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=20316"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20316\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20309"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20316"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20316"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}