Pro version customizes client automatic update

[Rocky-Jinxing]

I noticed that the latest rustdesk 1.4.0 client supports automatic updates. When will the Pro version of the customized client support automatic updates?

[Rocky-Jinxing]

Is there a plan to consider it? Because we found a bug in version 1.3.0. Versions below 1.3.0 had a bug in the Intel core graphics hardware acceleration, which caused a virtual memory leak. The bug was finally fixed after the release of version 1.3.1, but we had to manually reinstall version 1.3.1 on all machines. If this serious bug occurs again, we don’t want to manually upgrade one by one again, because now our number of client installations has reached more than 400.

[CryptoMears]

Yes this would be a great thing to have for sure. We are already at 304 devices installed. I just upvoted your comment.

[njc-paul]

If the custom client does not support auto-update why do standard users with no RD Service installed get a UAC Prompt to run the update script?

[Rocky-Jinxing]

It is known that all customized versions have a BUG. We have set the control end to initiate a connection only after logging in. The security audit-connection log will occasionally show the connection log of users who are not logged in. We have contacted your technical staff to solve this problem, but we have to update the controlled end, which is a nightmare for users who have installed 500 controlled ends.

[njc-paul]

Surely with 500 devices you have some kind of RMM or update tool that you could use to update?

[Rocky-Jinxing]

Surely with 500 devices you have some kind of RMM or update tool that you could use to update?

We don’t. We don’t monitor terminal devices. These 500 devices are distributed all over the world, and some are with our customers. So if we want to update them, we need to inform the customers in advance.

[Binary-Bandit64]

This is a needed feature. We use RMM with some clients and not with others. Manual work shouldn't be required to maintain reasonable security and fix bugs.

[CryptoMears]

Agree, Hoping this feature gets added pretty quickly, as you would think it would not be that hard to implement this request, and it should take top priority since it's a security concern that could have huge implications if a person's account gets compromised.

[Frankstar]

i like the idea in combination with #648
We could manually trigger the build process.
If build successfuly-> store the customclient on the self-hosted server.
Update clients from the self-hosted ressource.

i guess the clients would need an internal (UU)ID so each customclient can find the correct package.
Or maybe it would be possible to generalize and just update the "core" of the software and not the custom part?

[MikeT-KBU]

This is the best version. If Client is created downlod to server with a list of Available Clients and permanent link to it.
Admin can delete createt Clients.

[rustdesk]

@fufesou it is time to address this issue now.

[minz38]

Awesome, i cant wait to put my hands on this!

[ott-c]

I'll be able to switch away from a janky update script

[es4nn]

Great news

[rustdesk]

maybe it would be possible to generalize and just update the "core" of the software and not the custom part?

This is a good idea，and we verified it works, but the problem is many of our clients deploy clients in intranet without Internet access.

[njc-paul]

The updates should really come from the custom server, maybe a way around it would be for the custom server to download the client updates and the clients call them from there.

FYI: all my clients have internet access also

[rustdesk]

The updates should really come from the custom server, maybe a way around it would be for the custom server to download the client updates and the clients call them from there.

We will provide this option, you can choose to download from public or download from the link you give.

But the problem is how do we query the new version (not rely on internet any more)?

@fufesou

[Frankstar]

But the problem is how do we query the new version (not rely on internet any more)?

in my opinion the best option is to query an offical server.
alternatively, query the selfhosted server -> so the server needs that functionality -> an admin need to set a new offical version in an option and than the clients will update to that.

In my opinion the package should come from the offical server since we updating the core functionality.
This makes it more difficult to replace the code with malicious code.

[njc-paul]

I would rather the version be is set in the selfhosted server, the selfhosted server replicate official source, then updates primarily from selfhosted, if there is an issue with CRC match then official should be used and a warning\log on the selfhosted.

With regards to AV causing issues with updates, this should not be a problem if packages are signed, it is very rare for updaters to be identified as Virus, it does happen and in fact last week Edge updater got identified as malicious! this happens and you will never 100% be able to resolve that.

I am also happy to use RMM tools to deploy updates, you would need to work out how that happens, again my choice would still be for the version and installers to be hosted on my server, this would require the custom downloads existing for more than 1 day.

[Frankstar]

the selfhosted server replicate official source

i like this idea.

With regards to AV ...

i see it the same way.

[CryptoMears]

Yes, all my clients access the Internet from the RustDesk client.

[ConGp20]

Maybe a way to solve the problem could be to implement a downloads-page to rustdesk and also use this page to handle downloads.

[ichilver]

You would think a paid for licensed version of RustDesk Pro would have the same features (and more) than the free version.

A Internet facing RustDesk Server Pro with Internet capable clients should be able to receive auto updates for custom clients.

When you update the RustDesk Server Pro container to a new version there should be an option to rebuild all the custom clients (or manually from the custom clients page)

Once the rebuild to the latest version is done, all clients that are configured to myserver.example.com should then be offered new client to install.

Appreciate large installations will probably download the client and deploy to devices using their preferred tools, but for those that don't use deployment tools, this option would be really useful.

Maybe for each custom client you could add a field for a unique url path.

Example.

custom client 1 - myserver.example.com/download/some-name.msi
custom client 2 - myserver.example.com/download/some-other-name.msi
custom client 3 - not specified so not available for download and updates
custom client 4 - myserver.example.com/download/and-another-name.msi

That way the URLs can be locked in a "download" folder (also definable) and with some unique name that only you would know to prevent random downloads, but the URL would be define in the custom clients configuration so it could check for a new version and know where to download it from. Maybe even expose the "download" folder to a docker volume or docker local bind, to keep the container image growing unnecessarily.

This example would work for those on Intranet's as well, as long as DNS is setup correctly and the clients were on the same LAN or VPN.

This could even be extended to the Strategies where on selected strategies you could enable/disable the custom client update feature.

[Frankstar]

i still would prefer the "generalize and just update the "core" of the software and not the custom part" solution.
since its cleaner for everybody, the Devs, the Admin, the Users.
And that without rebuild any customclient on an update.

[ichilver]

I'd be happy with either option TBH. Any solution to update the client is better than no solution at all.

[m2avc]

I agree we really need an auto update. We're coming from Splashtop and we just need a solution to keep the clients up to date. These unmonitored headless computers are all over the world (mostly US) so updating is a manual process.

[rustdesk]

i still would prefer the "generalize and just update the "core" of the software and not the custom part" solution.

We have implemented it rustdesk/rustdesk#13687

But I'm sorry, we cannot release it in 1.4.5. It might be in 1.4.6.

I have seen many complaints in the TeamViewer subreddit about the auto-update interruption issue caused by antivirus or other unknown reasons. This makes me worry about its robustness, so I decided to do more testing before release.

I still think deploying and updating with RMM or deployment/distribution tools like Intune etc. is a better solution. But I know many users do not have these tools installed.

[Frankstar]

i love that you implemented an "Auto-Update" Option/Checkbox.
So User with an RMM can uncheck it.

will this option be availaible via Override settings/Default settings in Advanced Settings?

[rustdesk]

will this option be availaible via Override settings/Default settings in Advanced Settings?

Yes, it is off by default.