docs(posts): yum said 301, the machine said 2024 - #33
Conversation
A home lab XCP-ng 8.3 host refused the July update batch with "HTTPS Error 301 - Moved Permanently". The mirrors were healthy and the redirect chain was correct; the host believed it was September 2024, so every certificate it was offered failed its notBefore check. Underneath that, chronyd was both active and enabled while having zero sources configured, because /etc/chrony.conf shipped with no server or pool line at all. A time daemon in that state is indistinguishable from a healthy one unless you run chronyc sources. The post also walks through why yum reports the redirect rather than the TLS error: urlgrabber's header callback advances the scheme on Location, while the failed handshake never produces a response code, so the stale 301 from the successful hop wins and the real libcurl message is discarded.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Warning Review limit reached
Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds an AsciiDoc post explaining how an incorrect system clock and an unconfigured ChangesYum clock diagnosis
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/posts/2026-07-29-yum-said-301-the-machine-said-2024.adoc`:
- Around line 53-64: Clarify the mirror-validation section around the curl
command by stating that it must be run from a correctly synchronized host or
second machine, not the affected host with the 2024 clock. Ensure the diagnostic
output is presented as coming from that correctly timed environment, or replace
it with a diagnostic that remains valid on the affected host.
- Around line 243-247: Update the command sequence around “yum check-update” to
reflect that it only lists available updates and returns exit code 100 when
updates exist; add “yum update” before the narrative about installing the July
package batch, and revise the stated exit-code claim accordingly.
- Around line 216-235: Update the chrony recovery instructions after the
`/etc/chrony.conf` server entries to reload or restart the running `chronyd`
service, then rerun `chronyc sources` and confirm the configured sources are
active before continuing. Keep the existing `chronyc makestep` guidance, but
ensure the configuration reload occurs before the final source verification.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d4d56069-a24b-43e3-ab55-36b11bb0d085
⛔ Files ignored due to path filters (1)
static/assets/images/2026/07/29/00-header-rusted-clock.jpgis excluded by!**/*.jpg
📒 Files selected for processing (1)
content/posts/2026-07-29-yum-said-301-the-machine-said-2024.adoc
Three issues raised in review on the 2026-07-29 post. The chronyd recipe did not fix the host the post diagnoses. With zero sources configured, chronyc makestep has no measured offset to step to: it reports success and leaves the clock where it was. The text also referred to a restart it never gave. Split the recipe into the two cases, sources present versus sources empty, and make the restart and the follow-up chronyc sources explicit. The curl chain proving the mirrors healthy was run from a laptop, not from the failing host, which the text never said. On the affected host the same command dies at the handshake. Named the machine at the point the chain is shown, and explained the difference where the reader learns why it happens. Dropped the claim that yum check-update returned exit code 0 alongside 28 pending packages, which cannot both be true, and added yum update to the block since the narrative is about taking the batch. Noted the actual semantics: check-update returns 100 when updates are waiting.
The post originally claimed yum check-update returned exit 0 alongside 28 pending packages, which cannot happen. Verified against yum 3.4.3, the same generation dom0 runs: check-update exits 100 with updates pending and 0 with none, while yum update exits 0 on success. So the original 0 was a real observation attached to the wrong command rather than an invented number. Attribute it to yum update, which also puts it next to the note about check-update returning 100.
1 participant
A home lab XCP-ng 8.3 host refused the July update batch with
HTTPS Error 301 - Moved Permanently. Every word of that message points outward at the mirrors, and every word of it is about the wrong thing. The mirrors were healthy, the redirect chain was correct, and the host simply thought it was September 2024 — so every certificate it was offered failed itsnotBeforecheck.The reason this one is worth a post rather than a forum reply is what was underneath.
chronydwas both active and enabled, which is the state every check an operator would think to run reports as green. It also had zero sources, because/etc/chrony.confshipped with noserverorpoolline at all. A time daemon in that state is indistinguishable from a healthy one unless you specifically runchronyc sources, and nobody runs that until they already suspect the clock. So the host holds its install date indefinitely, and the first thing that ever tells you is an unrelated-looking yum error.There is also a walkthrough of why yum reports the redirect instead of the TLS failure: urlgrabber's header callback advances
self.schemethe moment it sees aLocation:, while a failed handshake never produces an HTTP response code — so the stale301from the hop that worked wins the format string, and libcurl's honestcertificate is not yet validis built and then thrown away.Notes for review
docs.xcp-ng.orglink until that merges.static/assets/images/2026/07/29/.10:00:00 +0200, not+0000. As+0000the post was ~2h in the future and Hugo silently dropped it from the build — it would have merged green and simply not appeared.+0200keeps the same date and the same "10:00" reading while being in the past. Verified the page builds without--buildFuture.Verification
asciidoctor --failure-level=WARNexits 0, no warningshugo --minify, v0.161.1 extended) completes with no warnings or errors/2026/07/29/yum-said-301-the-machine-said-2024/and appears in the homepage listing<img>carries the full alt text — the alt needed quoting, since AsciiDoc otherwise splits on the commas and turns the tail into boguswidthandheightattributesSummary by CodeRabbit
yumupdates on XCP-ng hosts.