This issue happened on a custom user environment where thin-edge.io was installed on a non-standard location due to the standard /usr/bin directory being non-writable, as such thin-edge was installed at /data/tedge. This is not achievable via normal installation methods and required a lot of tweaking, so it's not technically a bug. Nonetheless, we should allow users to customise their thin-edge.io installations if their environment requires it.

Describe the bug

When thin-edge.io is installed in a non-standard location and /usr/bin/tedge-write is not present, configuration update operation doesn't work:

2024-08-19T10:45:36.87635586Z ERROR tedge_config_manager::actor: config-manager failed writing updated configuration file: Starting tedge-write process failed

This happens because currently ConfigManagerActor always tries to use tedge-write when deploying configuration files.

tedge-write (#2456) is a mechanism to elevate tedge-agent's permissions to write to configuration files that tedge-agent doesn't normally have write permissions for because they're not owned by tedge, but perhaps e.g. root or mosquitto. tedge-agent spawns a sudo tedge-write SRC DST --user USER --group GROUP --mode MODE process, the contents of the source file are written into a destination file, and sudo allows tedge-write to write to a file that's normally not writable by tedge. For sudo to run tedge-write as root, there needs to be an entry in /etc/sudoers. By default the installation script generates the following entry which allows user tedge to execute /usr/bin/tedge-write as root without password when 1st argument matches /etc/*:

tedge    ALL = (ALL) NOPASSWD: /usr/bin/tedge-write /etc/*

sudo matches its command line arguments with the pattern in the sudoers entry, so for that reason it is crucial that a full path /usr/bin/tedge-write is used, or sudo won't run tedge-write as root. For the same reason the destination file needs to be the first argument, despite tedge-write command line parser allowing arguments to be provided in any order.

Because full path needs to be used, it is tricky to customise the path of tedge-write because the full path in sudoers entry needs to stay in sync as well. If a user changes location of tedge-write, they need to update their sudoers entry.

To Reproduce

1. Change the path of tedge-write to another location that is in tedge-agent process' $PATH, e.g.:

   mv /usr/bin/tedge-write /data/bin/tedge-write
   

2. Launch a config update operation from Cumulocity
3. Config update operation fails with:

   2024-08-19T10:45:36.87635586Z ERROR tedge_config_manager::actor: config-manager failed writing updated configuration file: Starting tedge-write process failed
   

Expected behavior

Operation completes successfully.

Environment (please complete the following information):

• thin-edge.io version: 1.2.1

Additional context

Currently, tedge-write is always used to deploy configuration files by ConfigManagerActor. This is completely unnecessary in cases where we already have necessary read/write permissions.

As such, the solution to this issue depends on some details that are intentionally missing in To Reproduce section, namely:

• if we have permissions, avoid calling tedge-write (config-manager: Only use tedge-write after normal copy fails due to permissions and improve tedge-write logging #3069)
• if we don't have permissions, find location of tedge-write via which, and then use that path to spawn a tedge-write process run tedge-write. If we again get a PermissionDenied, sudo didn't run tedge-write as root, so path in sudoers didn't match the path sudo found for tedge-write, and we need to notice the user (fix: tedge write remove hardcoded path #3099)
• add more documentation about tedge-write (docs: Add tedge-write documentation page #3116)
  • ensure binary --help is up to date
  • make reference available in web documentation
  • reference tedge-write in relevant sections, e.g. in configuration update document
• detect tedge-write misconfiguration as early as possible