One day in 2013, my manager walked up to me and said,“For TeamViewer 9, we’ll introduce TeamViewer QuickSupport for Linux.”
To which I replied, “Well, I’m not so sure that’s even possible.”
“But… we need it!”
“Okay then, let’s do it!”
Well… I admit, this wasn’t exactly how that talk went, but it makes a good and dramatic introduction, something along the lines of, “‘Scotty, how long will it take to fix the warp drive?’ ‘Four days at least!’ ‘We have four hours to escape this anomaly!’ ‘Okay then, I’ll do it in two!’”
Frankly, creating QuickSupport for Linux was quite different from “just adding some features to the package” and definitely not as straight forward as it has been on other platforms. Some of the paths we had to take may seem obvious, but I think some are not.
Support me quickly, please!
Admittedly, the QuickSupport package is a little bit bigger than the term “quick” might initially imply. I’ll explain why later, but it has to be a bigger download than the ordinary package. Be that as it may, there are a few things you definitely don’t want in a “quick support’.”
- deliberating with the customer to determine which download to pick (depending on their Linux flavor and architecture)
- explaining how to make a file executable
- having them check for the existence of half-a-dozen libraries
- describing how to obtain root permissions (ouch!)
- having them install foo2:i386, barlib, baz-11, and XYZ_server:i386
Chances are that either the supporter or the one in need of support has a nervous breakdown during the process – or they simply give up.
Just download and execute
With Linux, you generally cannot just download a file and execute it by (double) clicking on it. Usually this is a good thing as it prevents accidental execution of files you really don’t want to execute, like the infamous “your-invoice.pdf.exe” scams that users of other systems often fear.
For QuickSupport on Linux, this necessitates an extra step. After downloading the teamviewer_qs.tar.gz archive file, it has to be extracted. You’ll get a folder containing a teamviewer binary that you can execute by clicking on it. Of course, we could also create some teamviewer_qs.sh file and add a note “make executable after download,” but most users are much more familiar with extracting a file than with making it executable. A normal user does not even need to know what that means. However, he or she probably knows what to do with a tar.gz file. Chances are, the user already knows to just (right) click the file and “extract here.” Luckily, this feature exists in almost all desktop environments for Linux. If users don’t know about it, explaining it on the phone should be feasible.
On every Linux box, there are plenty of libraries present. A library is a file that provides functionality such as networking, encryption, or graphics algorithms used by various computer programs. This is essentially true for all operating systems, but due to the flexibility and variety of Linux distributions, you can’t merely assume the existence of the libraries you need. If you install an application on your Linux box, the package manager will make sure all dependencies are satisfied. If a library is missing, it’ll be installed.
For QuickSupport, this obviously does not work. We don’t want to install anything. We just want it to run. So, we include all the libraries. That’s basically it. This increases the download size, but other than that, it sounds pretty simple. For the most part, it is simple, unless of course you want to be sure that the package works on 99% of the machines out there in the wild. What follows is a lot of boring, tedious, and occasionally frustrating work, but I’ll spare you all the gory details.
Do you speak 01001100 11001100 01101100 01010111 ?
You probably know what happens if you open a file (e.g. image.jpg) by clicking on it, or if you run a shell script (myjob.sh); the system takes a look at the file and opens it with the appropriate program.
Did you know the same thing happens when you execute a binary? “But,” you may object, “which binary would I use to execute a binary?” Well, this binary is the loader: ld-linux.so on 32 bit machines and ld-linux-x86-64.so on 64 bit installations (Intel architecture).
Yes kids, you can even try this at home:
At least one of the commands will probably not succeed, even if all the files exist. Simply put, the loader has to match the binary. If your installation is 32 bit, you don’t have a 64 bit loader. If it’s a 64 bit machine, you may (or may not) have both loaders installed. That’s a problem for QuickSupport. It has to be 32 bit to work on 32 and 64 bit machines, but it also has to work on machines that don’t have a 32 bit loader present. The easy part is to ship the loader too. Oh, but which binary tells the system to use the shipped loader to run the shipped binary? In other words, how do you even make the command clickable?
to b-nary or not to b-nary
There’s actually a simple solution to this chicken-and-egg problem. Shell scripts are architecture-agnostic. So, you can just wrap the command line in a shell script:
In reality, the shell script is a bit more complex. For example, the paths cannot be hard wired because we just don’t know where the QuickSupport will be extracted. This is essentially what happens though, and it works quite well… until you find out that you cannot just execute a shell script by clicking on it on every system.
In some desktop environments, if you click a shell script, it will open a dialog asking if you want to “Run,” “Run in Terminal,” “Read,” or “Edit” the file. Way to go in confusing your help-seeking customer. However, it’s still better than those environments that don’t even bother asking and simply open the file in an editor. Depending on the skills of the user, such behavior ranges from minor annoyance to showstopper. So, we had to do something about it.
When I talked about loaders earlier, you may have wondered why a loader does not need a loader. Well, the chicken-and-egg problem must be resolved somehow, right?
The answer is this; a program binary usually needs libraries. Yeah, I know I mentioned that before. Well, the loader kind of connects the binary with the libraries it needs before it is brought to life. The loader itself is self-contained though. It does not use any libraries. Therefore, making a loader is a bit harder than writing ordinary programs. You can’t make use of the utilities others have created. It’s a bit like creating a jigsaw puzzle – without a jigsaw.
If we could write our own, architecture-agnostic little loader whose only purpose is to execute the shell script that, in turn, executes the shipped loader to run the shipped binaries, that would be awesome. So, it’s exactly what we did. A colleague of mine wrote this little masterpiece that allows you to run QuickSupport with only a click on just about every Linux powered PC out there.
Let there be support
If you managed to read this far and appreciated what you read, you’re most likely someone who offers support to others rather than being in need of support. So, what are you waiting for? If your family and friends ever want to give Linux a try, they can. If they need your help, they can easily use TeamViewer QuickSupport for Linux. If you happen to provide Linux support as part of your job, you might be interested in a customized QuickSupport module with your company colors, logo, and more. Try it out now!
[download url=”https://www.teamviewer.com/en/download/linux.aspx” style=”download” color=”green”]Download TeamViewer for Linux[/download]
[av_hr class=’invisible’ height=’50’ shadow=’no-shadow’ position=’center’ custom_border=’av-border-thin’ custom_width=’50px’ custom_border_color=” custom_margin_top=’30px’ custom_margin_bottom=’30px’ icon_select=’yes’ custom_icon_color=” icon=’ue808′ font=’entypo-fontello’]
[av_sidebar widget_area=’Related Posts’]
[av_sidebar widget_area=’General Article CTA’]