[GH-ISSUE #1363] Backup.sh directly overwrites itself #851

New issue

Closed

opened 2026-03-02 02:19:29 +03:00 by kerem · 4 comments

kerem commented

2026-03-02 02:19:29 +03:00

Owner

Originally created by @azulskyknight on GitHub (Dec 6, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1363

Originally assigned to: @dinger1986, @wh1te909 on GitHub.

As shown here:

if [ "${SCRIPT_VERSION}" -ne "${NEW_VER}" ]; then printf >&2 "${YELLOW}Old backup script detected, downloading and replacing with the latest version...${NC}\n" wget -q "${SCRIPT_URL}" -O backup.sh exec ${THIS_SCRIPT} fi

backup.sh overwrites itself directly. This creates a risk of a bad download corrupting the script on execution as happened to my TRMM server Sunday with the release of v0.15.4. I didn't immediately notice this and it disabled the cronjob on my server halting backups effective Sunday night until I noticed this afternoon.

I suggest the script be enhanced to do as NiceGuyIT suggested in Discord, download to a temporary file, verify it and then copy it into place.

Originally created by @azulskyknight on GitHub (Dec 6, 2022). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1363 Originally assigned to: @dinger1986, @wh1te909 on GitHub. As shown here: `if [ "${SCRIPT_VERSION}" -ne "${NEW_VER}" ]; then printf >&2 "${YELLOW}Old backup script detected, downloading and replacing with the latest version...${NC}\n" wget -q "${SCRIPT_URL}" -O backup.sh exec ${THIS_SCRIPT} fi` backup.sh overwrites itself directly. This creates a risk of a bad download corrupting the script on execution as happened to my TRMM server Sunday with the release of v0.15.4. I didn't immediately notice this and it disabled the cronjob on my server halting backups effective Sunday night until I noticed this afternoon. I suggest the script be enhanced to do as NiceGuyIT suggested in Discord, download to a temporary file, verify it and then copy it into place.

kerem

2026-03-02 02:19:29 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-02 02:19:30 +03:00

Author

Owner

@silversword411 commented on GitHub (Dec 31, 2022):

https://discord.com/channels/736478043522072608/889513877124042762/1049758209507860640

if [ "${SCRIPT_VERSION}" -ne "${NEW_VER}" ]; then
    printf >&2 "${YELLOW}Old backup script detected, downloading and replacing with the latest version...${NC}\n"
    wget -q "${SCRIPT_URL}" -O backup.sh
    exec ${THIS_SCRIPT}
fi

@silversword411 commented on GitHub (Dec 31, 2022): https://discord.com/channels/736478043522072608/889513877124042762/1049758209507860640 ``` if [ "${SCRIPT_VERSION}" -ne "${NEW_VER}" ]; then printf >&2 "${YELLOW}Old backup script detected, downloading and replacing with the latest version...${NC}\n" wget -q "${SCRIPT_URL}" -O backup.sh exec ${THIS_SCRIPT} fi ```

kerem commented

2026-03-02 02:19:30 +03:00

Author

Owner

@dinger1986 commented on GitHub (Dec 31, 2022):

That's what the script does at the moment. Shall work on it

@dinger1986 commented on GitHub (Dec 31, 2022): That's what the script does at the moment. Shall work on it

kerem commented

2026-03-02 02:19:30 +03:00

Author

Owner

@wh1te909 commented on GitHub (Mar 21, 2023):

I am actually removing the auto update feature of the backup script. Since the backup script is usually ran before an update, if it downloads and replaces itself with the newer version then the backup script will actually have the latest changes that are designed for the latest update, while the repo code hasn't been actually updated on the user's system yet, which could cause the backup script to fail as it references newer code that isn't yet on the system. Therefore the backup script must be manually managed and only replaced after the upgrade script has been ran.

@wh1te909 commented on GitHub (Mar 21, 2023): I am actually removing the auto update feature of the backup script. Since the backup script is usually ran before an update, if it downloads and replaces itself with the newer version then the backup script will actually have the latest changes that are designed for the latest update, while the repo code hasn't been actually updated on the user's system yet, which could cause the backup script to fail as it references newer code that isn't yet on the system. Therefore the backup script must be manually managed and only replaced after the upgrade script has been ran.

kerem commented

2026-03-02 02:19:30 +03:00

Author

Owner

@silversword411 commented on GitHub (Mar 22, 2023):

Therefore the backup script must be manually managed and only replaced after the upgrade script has been ran.

Should we update the docs so that the backup script is treated like the mesh troubleshooting script...just run from local file/as of last update?

https://docs.tacticalrmm.com/troubleshooting/#agents-not-installing-or-updating

Maybe update server_troubleshooting too...so it's running from last update files https://docs.tacticalrmm.com/troubleshooting/#server-troubleshooting-script

@silversword411 commented on GitHub (Mar 22, 2023): > Therefore the backup script must be manually managed and only replaced after the upgrade script has been ran. Should we update the docs so that the backup script is treated like the mesh troubleshooting script...just run from local file/as of last update? https://docs.tacticalrmm.com/troubleshooting/#agents-not-installing-or-updating Maybe update server_troubleshooting too...so it's running from last update files https://docs.tacticalrmm.com/troubleshooting/#server-troubleshooting-script

kerem referenced this issue

2026-03-14 04:12:40 +03:00

[GH-ISSUE #851] x509 certificate signed by unknown authority - Installing Agent Windows 10 #2481