From 881e5724f5a6bfa241a65c7f071448810647f14f Mon Sep 17 00:00:00 2001 From: Chad Wilson Date: Wed, 6 Nov 2024 10:05:05 +0800 Subject: [PATCH] Update broken links --- source/partials/release_notes/_release-24-1-0.md.erb | 2 +- ...ploy-package-not-just-tag-branch-or-binary.html.markdown.erb | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/source/partials/release_notes/_release-24-1-0.md.erb b/source/partials/release_notes/_release-24-1-0.md.erb index 45a8392dab..72d6a742f7 100644 --- a/source/partials/release_notes/_release-24-1-0.md.erb +++ b/source/partials/release_notes/_release-24-1-0.md.erb @@ -48,7 +48,7 @@ changes within these versions. If you have any further queries/issues, please as The GoCD server container has always been based on a minimal Linux distribution, previously [Alpine Linux](https://alpinelinux.org/), but from 24.1.0 has been switched to [Wolfi OS](https://github.com/wolfi-dev). Wolfi OS is a similarly minimal, security-oriented (un)distro from the folks at [Chainguard](https://www.chainguard.dev/) which is -[optimized for supply-chain security](https://www.chainguard.dev/unchained/introducing-wolfi-the-first-linux-un-distro) - +[optimized for supply-chain security](https://www.chainguard.dev/unchained/introducing-wolfi-the-first-linux-un-distro-designed-for-securing-the-software-supply-chain) - and unlike the _musl_-based Alpine uses _glibc_, similar to most other distributions. Unfortunately, the use of Alpine has always posed difficulties due to its musl libc base. Most of the time this is an diff --git a/source/posts/2014-02-24-deploy-package-not-just-tag-branch-or-binary.html.markdown.erb b/source/posts/2014-02-24-deploy-package-not-just-tag-branch-or-binary.html.markdown.erb index 92e8f65243..91fbf2c0dc 100644 --- a/source/posts/2014-02-24-deploy-package-not-just-tag-branch-or-binary.html.markdown.erb +++ b/source/posts/2014-02-24-deploy-package-not-just-tag-branch-or-binary.html.markdown.erb @@ -23,7 +23,7 @@ We concur. This is a good example of cross-pollination of good ideas between dev 4. Transactional install/upgrade/uninstall via package managers. 5. Managing configuration files: OS packages know how to manage files that are expected to change after installation so you don't lose your changes when you uninstall or override when you upgrade. e.g. rpm's %config macro. 6. File verification: Packages have built-in checksums, which can be used for verification before a package is extracted and installed. -7. Signature verification (e.g. [rpm](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-check-rpm-sig)). +7. Signature verification (e.g. [rpm](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/5/html/deployment_guide/s1-check-rpm-sig)). 8. Idempotence - Issuing the same package install/upgrade/uninstall multiple times leaves the system in the same state as issuing it once. 9. Auditability: OS packaging tools allows you to track [what package installed what file](https://unix.stackexchange.com/questions/4705/how-to-find-out-which-package-a-file-belongs-to) in your system (versus files appearing or being changed at will) 10. Traceability - what repository did a package come from? (e.g. deb)