docs: Clarify first boot registration service#1751
docs: Clarify first boot registration service#1751m-horky wants to merge 1 commit intobootc-dev:mainfrom
Conversation
41b068d to
de557b8
Compare
There was a problem hiding this comment.
Code Review
This pull request clarifies the documentation for a first-boot registration service. It improves the wording, fixes typos, removes a duplicated command, and corrects a significant bug in the example systemd service where a wrong path was used in ConditionPathExists. These changes greatly improve the clarity and correctness of the documentation. I have added one comment with a suggestion to further improve the robustness of the systemd service example, ensuring it can retry on failure and that credentials are securely cleaned up.
| ExecStartPre=/bin/rm -f /etc/management-client/.register-on-first-boot | ||
| ExecStart=/usr/bin/management-client register --activation-key ${CLIENT_ACTIVATION_KEY} | ||
| ExecStartPre=/bin/rm -f /etc/management-client/.run_next_boot | ||
| ExecStop=/bin/rm -f /etc/management-client/.credentials |
There was a problem hiding this comment.
There are a couple of issues with the current service definition that could lead to unexpected behavior:
-
Registration retry: Using
ExecStartPreto remove the condition file (.register-on-first-boot) means that if the registration inExecStartfails (e.g., due to a transient network error), the service won't attempt to register again on the next boot. The condition file should only be removed upon successful registration. -
Credential cleanup: For a
Type=oneshotservice withoutRemainAfterExit=yes,ExecStopis not executed when theExecStartcommand completes. This means the credentials file (/etc/management-client/.credentials) will not be removed as intended, leaving secrets on the disk.
A more robust approach is to handle both the conditional file removal and credential cleanup within a single ExecStart command. The suggested change below implements this. The trap command ensures /etc/management-client/.credentials is removed when the shell exits, regardless of success or failure. The && ensures /etc/management-client/.register-on-first-boot is only removed if the registration command is successful.
| ExecStartPre=/bin/rm -f /etc/management-client/.register-on-first-boot | |
| ExecStart=/usr/bin/management-client register --activation-key ${CLIENT_ACTIVATION_KEY} | |
| ExecStartPre=/bin/rm -f /etc/management-client/.run_next_boot | |
| ExecStop=/bin/rm -f /etc/management-client/.credentials | |
| ExecStart=/bin/sh -c "trap '/bin/rm -f /etc/management-client/.credentials' EXIT; /usr/bin/management-client register --activation-key ${CLIENT_ACTIVATION_KEY} && /bin/rm -f /etc/management-client/.register-on-first-boot" |
There was a problem hiding this comment.
This feedback is valid, but I didn't want to alter the existing behavior. For an example, I believe the current version is sufficient.
There was a problem hiding this comment.
Looks like the original doc had this wrong. This should be in ExecStartPost
de557b8 to
2f4f834
Compare
|
Just make a rebase for |
2f4f834 to
cc615a0
Compare
The original text roughly contained the steps to set up a service to register with on the next (first) boot, but contained some minor issues. Aside from typos/phrasing: - It talked of 'startup' and 'next boot', but effectively this would only get executed on first boot. - Command `touch .run_next_boot` was contained twice. Signed-off-by: mhorky <[email protected]>
cc615a0 to
af6f0e5
Compare
The original text roughly contained the steps to set up a service to register with on the next (first) boot, but contained some minor issues. Aside from typos/phrasing:
touch .run_next_bootwas contained twice.