Configuration and updates

Automatic updates and service reloads

Understand update-certificate, script review, .bak backups, service reloads, and success, failure, and rollback logs.

Last reviewed: 2026-08-31Language: English

This page describes the complete clmbot certificate-update workflow: the update command, pre- and post-update scripts, backups, service reloads, and log review.

The update-certificate command

./clm-bot-linux-amd64 update-certificate

The command performs these steps in order:

  1. Check: ask the upstream whether a new certificate is available.
  2. Retrieve: download the new certificate to the server.
  3. Back up: copy the old certificate to a .bak file in the certificate directory before replacement.
  4. Replace: write the new certificate to paths defined by servers[] in config.yaml.
  5. Reload: run after_script, such as a service reload, to activate the new certificate.

If no certificate is available, the command exits normally without changing files. Run it manually or periodically through a Scheduled pull task.

Review requirements for before_script and after_script

  • before_script runs before certificate replacement for preparation.
  • after_script runs after replacement and usually contains a middleware reload or restart command, such as nginx -t && nginx -s reload.

Required review rules:

  • Review every line manually before enabling a script.
  • Scripts run with the privileges of the clmbot account. Grant elevated commands through exact sudoers rules. See Least privilege.
  • Do not allow unrestricted bash, powershell.exe, or complete systemctl access.
  • Do not place plaintext credentials in a script.

Certificate backups and rollback

  • Before each replacement, clmbot stores the old certificate as a .bak file. The runtime account needs permission to create and remove .bak files in the certificate directory.
  • If the new certificate causes a service problem, restore the old file manually from .bak and reload the service.
  • The public documentation defines a manual .bak recovery process. Do not assume that the program performs an automatic rollback.

Service reloads

after_script reloads the service. See Least privilege for recommended commands and exact authorization patterns:

  • Nginx: nginx -t && nginx -s reload.
  • Apache: systemctl restart httpd.service or systemctl restart apache2.service, depending on the distribution.
  • Tomcat: run shutdown.sh and startup.sh for the target instance.
  • IIS: use a PowerShell script to import PFX and update the HTTPS binding.

Success, failure, and rollback logs

  • Scheduled-task examples append output to update.log in the runtime directory with >> update.log.
  • Inspect logs regularly to confirm whether a certificate was found, replacement succeeded, and after_script completed.
  • When an update fails, inspect the error first and work through Troubleshooting.
  • Log format may change by release. Evaluate the exit status, terminal output, and service checks together.
  • Logs may contain hostnames, paths, and other sensitive information. Sanitize them before sharing. See Security.