How to handle remote target machines with different os versions
-
I hope this is the right section of the forum for my question.
I learned the hard way that the binaries built with a specific Linux version are not (usually) compatible with another version, even of the same distro (i.e. Ubuntu 21.04 vs 22.04).
On the other hand, often is not advisable to upgrade all the systems to the very latest version.
I'm looking for some advices about how to maintain (remote) machines with different versions of Linux. To be clear, my scenario is the following.
Every, 5-6 months I have to configure a new remote machine with an Ubuntu distro. When possible, of course, I try to stick on the latest LTS version, but is not always possible.So in the years, I ended up with several machines with different Ubuntu versions, even different than my own dev machine.
This is a mess when you need to upgrade the software (Qt).
I found only a couple of solutions but none is the best:-
prepare a VM for each installation with the very same version of the target. Downsides: you lost the advantages of writing code in a real machine (instead of VM) and you need to keep saved a lot of images
-
periodically upgrade all the machines. Downsides: it's time consuming, error prone, you can hang the whole system, often the customer does not allow you to upgrade
-
install the build tools on the remote machines. Downsides: you need to double the work (dev+target)
Any other idea?
-
-
I hope this is the right section of the forum for my question.
I learned the hard way that the binaries built with a specific Linux version are not (usually) compatible with another version, even of the same distro (i.e. Ubuntu 21.04 vs 22.04).
On the other hand, often is not advisable to upgrade all the systems to the very latest version.
I'm looking for some advices about how to maintain (remote) machines with different versions of Linux. To be clear, my scenario is the following.
Every, 5-6 months I have to configure a new remote machine with an Ubuntu distro. When possible, of course, I try to stick on the latest LTS version, but is not always possible.So in the years, I ended up with several machines with different Ubuntu versions, even different than my own dev machine.
This is a mess when you need to upgrade the software (Qt).
I found only a couple of solutions but none is the best:-
prepare a VM for each installation with the very same version of the target. Downsides: you lost the advantages of writing code in a real machine (instead of VM) and you need to keep saved a lot of images
-
periodically upgrade all the machines. Downsides: it's time consuming, error prone, you can hang the whole system, often the customer does not allow you to upgrade
-
install the build tools on the remote machines. Downsides: you need to double the work (dev+target)
Any other idea?
@Mark81 Use AppImage or Flatpack to generate binaries which will work on (almost) any Linux system.
Take a look at https://github.com/probonopd/linuxdeployqt for example.
-
-
@Mark81 Use AppImage or Flatpack to generate binaries which will work on (almost) any Linux system.
Take a look at https://github.com/probonopd/linuxdeployqt for example.
@sierdzio that's interesting! What I missed to highlight in my question is I need to develop the application debugging on the target machine, since usually I have to control PLC or other external devices I cannot simulate at home.
Hence, I think the AppImage or Flatpack is a great advice for simple application I don't need to develop/debug remotely.
-
Right, I misunderstood. For debugging, AppImage won't help much.
So what are you trying to achieve actually?
- debug how your Qt code behaves on different OSes?
- debug how your Qt code behaves on different Qt versions?
- debug some bugs on client machines?
In case of 1 - I think best way is to have some VMs.
In case of 2 - you can install multiple version of Qt on your developer machine, no need for any other complication.
In case of 3 - you have to go to clients machines anyway and you can't test it on your side so... not much you can do. I guess, when you're called to fix something you can go there, install debug tools, debug the problem, then uninstall them and go back to your place.... but I guess I'm still not understanding this right :D
-
Right, I misunderstood. For debugging, AppImage won't help much.
So what are you trying to achieve actually?
- debug how your Qt code behaves on different OSes?
- debug how your Qt code behaves on different Qt versions?
- debug some bugs on client machines?
In case of 1 - I think best way is to have some VMs.
In case of 2 - you can install multiple version of Qt on your developer machine, no need for any other complication.
In case of 3 - you have to go to clients machines anyway and you can't test it on your side so... not much you can do. I guess, when you're called to fix something you can go there, install debug tools, debug the problem, then uninstall them and go back to your place.... but I guess I'm still not understanding this right :D
@sierdzio sorry, I understand it's not easy to answer and it's not easy to describe the scenario as well.
Point 2 - yes, this is already addressed, no prob
Point 3 - I do remote debugging, without the need to go to customers' places. I use a remote desktop for external application and a VPN tunnel to launch a debug session on my local dev machine, that runs on the target
Point 1 - quite correct, I don't need to debug "how" my Qt code behaves on different OSes, but I just need to run it :)
Basic example: right now, my dev machine runs Ubuntu 22.04, but some remote machines have Ubuntu 20.04. Even with the very same Qt version, the binaries are not compatible. Hence, if one of those customers would ask me even a simple change, I'm stuck. I have to install a VM with Ubuntu 20.04 and all the stuff just for, say, a couple of lines of code.
I was wondering if there was a smarter solution, like a "cross-compilation" for different Ubuntu versions (I install only this distro, just the version changes).
Installing the dev tools on the remote machine can be a solution, but, again, I lose the advantage of writing code on my local machine. Writing code inside a remote desktop is a pain...
-
@sierdzio sorry, I understand it's not easy to answer and it's not easy to describe the scenario as well.
Point 2 - yes, this is already addressed, no prob
Point 3 - I do remote debugging, without the need to go to customers' places. I use a remote desktop for external application and a VPN tunnel to launch a debug session on my local dev machine, that runs on the target
Point 1 - quite correct, I don't need to debug "how" my Qt code behaves on different OSes, but I just need to run it :)
Basic example: right now, my dev machine runs Ubuntu 22.04, but some remote machines have Ubuntu 20.04. Even with the very same Qt version, the binaries are not compatible. Hence, if one of those customers would ask me even a simple change, I'm stuck. I have to install a VM with Ubuntu 20.04 and all the stuff just for, say, a couple of lines of code.
I was wondering if there was a smarter solution, like a "cross-compilation" for different Ubuntu versions (I install only this distro, just the version changes).
Installing the dev tools on the remote machine can be a solution, but, again, I lose the advantage of writing code on my local machine. Writing code inside a remote desktop is a pain...
@Mark81 Hi,
If you have several customers with this Linux distribution, you should really consider having a machine with it. It will also make things easier to debug as you would have the same environment beside the PLC part.
I would also recommend mocking the PLC so you would be able in some limited extent to validate and test functionalities without requiring the hardware.
-
@Mark81 Hi,
If you have several customers with this Linux distribution, you should really consider having a machine with it. It will also make things easier to debug as you would have the same environment beside the PLC part.
I would also recommend mocking the PLC so you would be able in some limited extent to validate and test functionalities without requiring the hardware.
@SGaist said in How to handle remote target machines with different os versions:
you should really consider having a machine with it. It will also make things easier to debug as you would have the same environment beside the PLC part.
One machine for each Ubuntu release? Yep, this is the straightforward way, but quite ugly to be honest...
-
@SGaist said in How to handle remote target machines with different os versions:
you should really consider having a machine with it. It will also make things easier to debug as you would have the same environment beside the PLC part.
One machine for each Ubuntu release? Yep, this is the straightforward way, but quite ugly to be honest...
Using chroot might be an alternative as well.
