NoTouch OS allows you to install arbitrary 3rd party Linux applications, within certain limits to protect security and manageability of your NoTouch installation.
- 1 Required know-how
- 2 Support limitations
- 3 General considerations
- 4 Storing your application
- 5 Executing your application
- 6 Accessing read-only locations
- 7 Roll-out considerations
- 8 Usability considerations
If you do this on your own, a great amount Linux know-how is necessary. You need to be familiar at least with
- command line login in Linux: SSH login#NoTouch OS
- copying files around with scp: File exchange
- editing files with the vi editor: 
You will also need to know if your 3rd party module is just an application, or if it also brings kernel level drivers (sometimes the case with VPN clients or device-specific software). Also please be advised that nothing, really nothing is done "in just an hour". If you are in IT long enough, you will certainly agree. Such things always take longer than expected. If you don't feel comfortable doing that on your own, please ask your favorite Stratodesk representative and we can do that whole thing for you.
Note: While we can install 3rd party applications for you and even provide OS images with custom software as a professional service, we can not support YOU installing third party applications doing it yourself. No, it is not "just tell me this one command I need to execute". Installing 3rd party applications is NOT covered by our free support tier. Either we do it in total (as a professional services project), or we don't support it at all!
Here are the things to consider:
- NoTouch images are immutable and can not be modified after build, not even after installation. This differs dramatically from other (desktop or server) Linux variants and especially from inferior Thin Client OS type Linux variants.
- If you boot NoTouch and write e.g. to /etc or other foldes, these writes take place in RAM only. If you reboot, everything will be gone.
Practically speaking, since NoTouch OS is based on Linux, it can execute any Linux-Intel binary. You may have to add libraries that are not present in NoTouch but are in a big Linux system, but that is about it. Given the two constraints above, if you legitimately want to install 3rd party applications, you need to think about:
- Where would you store your third party software? Do you want to store it persistently on hard disk, or download on every boot?
- How do you want to execute your third party software (on boot, on user action, etc)?
- How - if at all - will you update your third party software?
- Is it ok to have the application only on a handful of machines or do you require them to be rolled out with your NoTouch roll-out or installed afterwards.
Storing your application
In general you have two choices:
- Use the space in /config for persistent storage - /config is the only folder that allows files to be stored persistently
- Download on every boot to /tmp to use the RAM disk. In this case you might use an event script with a wget-like command line and executing what you downloaded.
Note: For very obvious reasons, if you boot from CD-ROM, /config will also be a RAM disk.
Executing your application
Accessing read-only locations
Sometimes you need to access locations in the filesystem tree that are read-only. As they are read-only you can not write to them persistently but you can create a RAM-disk overlay and then write to these locations. All your changes are reset when you reboot the machine. So you have to redo calling the following commands every time after boot. This helps with consistency and avoids a system administration nightmare, it is a feature in your favor. To make a directory writeable with this method, use this command:
Please note that in some cases (depending on location and fs stack) you may have to use a trailing slash, such as mktmpovl /my/dir/.
If you go down the wget route, you don't have to think much about roll-out. Every machine that gets the your wget command line in one of the event scripts will just do as desired. If you install by logging in, copying files to /config manually, you'll have to re-do this (manually) on every machine. For the initial rollout, you can package your third party application via Configuration preload.
Depending on what your application is, very different problems may arise.
- User files storage. For instance, if you install OpenOffice, where will users store their files? Well yes there are solutions, you could use shared drives, a Dropbox client, etc, we just want to you think about this as well.
- Local windows vs. fullscreen desktops. If you are sharing full-screen desktops via e.g. Citrix or VMware Horizon View, a local GUI application will get in the way of that - end users will be confused, switching from the fullscreen Windows desktop to the local application requires Hotkeys.
- Localization. Your installed software may not be available in the language of your end users or maybe it is not capable of switching language. For instance, you might have Citrix-published applications in another language, but your own installed application may be available in English only causing complaints from end users.