diff --git a/docs/client/explanation/architecture/what-kind-of-updates-are-not-provided-by-livepatch.md b/docs/client/explanation/architecture/what-kind-of-updates-are-not-provided-by-livepatch.md index 5e8be16..cec76dc 100644 --- a/docs/client/explanation/architecture/what-kind-of-updates-are-not-provided-by-livepatch.md +++ b/docs/client/explanation/architecture/what-kind-of-updates-are-not-provided-by-livepatch.md @@ -12,7 +12,7 @@ The Livepatch service provides patches exclusively for Canonical-released kernel Live kernel patches are intended to address significant security issues in the kernel and provide protection from serious vulnerabilities until a reboot can be scheduled. All CVEs rated as high or critical will be fixed through live kernel patching whenever possible. If a live patch cannot be produced, the Livepatch Client issues a notification that a reboot is required. -Many patches included in [kernel updates](https://wiki.ubuntu.com/KernelTeam/KernelUpdates) are outside the scope of the Livepatch service, including: +Many patches included in [kernel updates](https://ubuntu.com/kernel/docs/explanation/post-release-updates/#what-sort-of-updates-are-allowed-for-post-release-kernels) are outside the scope of the Livepatch service, including: - Bug fixes that are not security issues - Performance improvements diff --git a/docs/client/explanation/troubleshooting/do-i-need-to-reboot.md b/docs/client/explanation/troubleshooting/do-i-need-to-reboot.md index 66c2a67..8192038 100644 --- a/docs/client/explanation/troubleshooting/do-i-need-to-reboot.md +++ b/docs/client/explanation/troubleshooting/do-i-need-to-reboot.md @@ -18,7 +18,7 @@ Several other software components can require a system reboot, including: Enabling the Livepatch service does not turn on automatic installation of security updates in APT. For best security, you should: -- [Enable security updates using APT](https://help.ubuntu.com/community/AutomaticSecurityUpdates) +- [Enable security updates using APT](https://documentation.ubuntu.com/server/how-to/software/automatic-updates/) - Subscribe to the [security announcement mailing list](https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce) - Follow all advised security updates and reboot at your earliest convenience when any software component requires it diff --git a/docs/client/explanation/troubleshooting/why-livepatch-is-not-working-on-my-machine.md b/docs/client/explanation/troubleshooting/why-livepatch-is-not-working-on-my-machine.md index 6cd1019..d6337cd 100644 --- a/docs/client/explanation/troubleshooting/why-livepatch-is-not-working-on-my-machine.md +++ b/docs/client/explanation/troubleshooting/why-livepatch-is-not-working-on-my-machine.md @@ -37,7 +37,7 @@ Newer releases of LTS Ubuntu Desktop default to the HWE kernel, meaning your mac Livepatch supports the GA kernel and the HWE kernel that you settle on with the next LTS. It does not fully support the interim kernels released every 6 months. This is why a machine running an LTS Ubuntu Desktop release may still display Livepatch messaging indicating that the kernel is not supported. -You can switch from an HWE kernel to the GA kernel by following the [LTS Enablement Stack instructions](https://wiki.ubuntu.com/Kernel/LTSEnablementStack). Back up your data and important information before making system-level changes. +You can switch from an HWE kernel to the GA kernel by following the [LTS Enablement Stack instructions](https://ubuntu.com/kernel/docs/reference/hwe-kernels/). Back up your data and important information before making system-level changes. Prior to Ubuntu 22.04 LTS, Livepatch offered no support for interim kernel versions. Livepatch has since added support for some flavours of interim HWE kernels. Desktop user kernels are the "generic" flavour, while public cloud kernels have their own unique flavours supporting cloud-specific functionality. Livepatch is now supported on interim HWE kernels for various public cloud flavours. Check your kernel flavour with `uname -r`. @@ -53,4 +53,4 @@ To import the Livepatch key: sudo mokutil --import /snap/canonical-livepatch/current/keys/livepatch-kmod.x509 ``` -Enter a password if prompted by MOK, then reboot. Your BIOS will guide you through enrolling the new key in MOK. After enrollment, you can verify the module signatures. \ No newline at end of file +Enter a password if prompted by MOK, then reboot. Your BIOS will guide you through enrolling the new key in MOK. After enrollment, you can verify the module signatures. diff --git a/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-k8s-operator-charm.md b/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-k8s-operator-charm.md index a7e5654..2fe8215 100644 --- a/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-k8s-operator-charm.md +++ b/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-k8s-operator-charm.md @@ -144,12 +144,21 @@ To migrate the PostgreSQL database from the machine charm environment to the K8s sudo apt install postgresql-client postgresql-client-common ``` -Next, run the `get-password` action on the PostgreSQL charm: +Next, retrieve the `operator` user's password. First, switch back to the machine charm model: ```bash -juju run postgresql/leader get-password +juju switch ``` +The PostgreSQL charm stores its internal system-user passwords in a [Juju secret](https://canonical-charmed-postgresql-single-kernel.readthedocs-hosted.com/16/how-to/authentication/manage-passwords/). List the model's secrets to find the one owned by the `postgresql` application, then reveal its contents: + +```bash +juju secrets +juju show-secret --reveal +``` + +The revealed secret includes the `operator-password` field, which you'll use in the next step. + Finally, dump the database using the IP address from earlier: ```bash diff --git a/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-snap.md b/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-snap.md index f7b7f29..d946616 100644 --- a/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-snap.md +++ b/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-snap.md @@ -131,12 +131,15 @@ This setup can differ on a case by case basis and would result in slightly diffe |------|----------|--------------|----------------------|--------|------------| |postgresql/0\*| active| 1 | 10.239.140.105| 5432/tcp | Primary -3. Get the system user's password for the PostgreSQL database charm unit. The password is obtained by using the [`get-password` action](https://charmhub.io/postgresql/actions#get-password) defined by the PostgreSQL machine charm. The action gets the password for the `operator` username by default. The action must be run for the unit configured to be the primary database. +3. Get the system user's password for the PostgreSQL database charm unit. The PostgreSQL machine charm stores its internal system-user passwords in a [Juju secret](https://canonical-charmed-postgresql-single-kernel.readthedocs-hosted.com/16/how-to/authentication/manage-passwords/). List the model's secrets to find the one owned by the `postgresql` application, then reveal its contents to obtain the `operator` user's password: ```shell - juju run postgresql/0 get-password + juju secrets + juju show-secret --reveal ``` + The revealed secret includes the `operator-password` field. + 4. Dump the database data from the PostgreSQL unit, using the [pg_dump tool](https://www.postgresql.org/docs/14/app-pgdump.html). The command below will prompt the `operator` user for a password, at which point the password obtained from the previous step needs to be entered. ```shell