adding .exe subprocess on windows host

georgebaileyster commented 1 year ago

Hi, is there a simple way to manually install an .exe sub-process under a windows host OS? It is already a pre-built standalone application. Thanks for any suggestions.

tobychui commented 1 year ago

Hi @georgebaileyster ,

You can refer to this subervice example on how to setup a bat script to start your own exe file. https://github.com/aroz-online/syncthing

Requirements

In general, your exe must satisfy the following requirements in order to be start with ArozOS

Your application provide a command line configurable web interface port (i.e. startup parameter contains something like -port 8080)
Your application must not spawn & detach another process (i.e. the process id of the exe which ArozOS start will not terminate itself after ArozOS execute it)
The application must support the same CPU architecture and OS of the host ArozOS one (i.e. Windows x64 version of ArozOS must use a windows x64 .exe file as subservice)

Setup Folder Structure

If your exe files satisfy the above requirement, you can put the exe file under the subservice folder under ArozOS root folder. It is recommend that the exe file follows the name of the folder. For example, you have a exe named "runthis.exe", then you can name your folder "runthis" , so the whole path will be

./subservice/runthis/runthis.exe

and then, you create an empty text file name .startscript next to your exe, this will notify ArozOS to launch your application using ths start.bat file instead of directly starting the exe file.

Finally, create a file name start.bat with the following contents

runthis.exe -port=127.0.0.1%2

ArozOS will pass two parameters to the application, where %2 is the port in which your exe file should launch its web UI on. The port name will include ":" in front of the number (e.g. :8080 instead of just 8080). Use something like set "param=%2" or set "param=!param:~1!" if you want to trim off the ":".

Setup Launch Modes

In order to let ArozOS knows how to launch your exe, you will also need a file named moduleInfo.json. This will tell ArozOS how to start your exe file web ui in its web desktop interface. Here is an example from the Syncthing repo

{
    "Name":"Syncthing",
    "Desc":"Open Source Continuous File Synchronization",
    "Group":"Download",
    "IconPath":"syncthing/assets/img/favicon-sync.png",
    "Version":"1.5.0-rc.2",
    "StartDir":"syncthing/#",
    "SupportFW":true,
    "LaunchFWDir":"syncthing/#",
    "InitFWSize":[1200,670]
}

Most of the options here are easy to understand. The most important one is StartDir, which is the path of the web ui is required to load. Generally, if you access your exe file web UI (assuming localhost) at

http://localhost:8080/webui/

Then for StartDir, you need to fill in runthis/webui/ (The folder name of your subservice, then the remaining sub-paths of the web UI, basically replacing the domain with the folder name of subservice), LaunchFWDir and optionally Embedded are for launching under float window mode (open in web desktop) and embedded mode (passing a file to your exe). You can just set those to the same path as StartDir if no optimization is required.

After the setup is done, restart your ArozOS and you will be able to see your subservice show up in ArozOS.

georgebaileyster commented 1 year ago

Hi Toby,

Many thanks for the insight will take a closer look over the weekend.

However, I have noticed that there is no apparent way to block users from accessing the management gateway / system settings. This obviously means there is in fact no user control a anyone can do everything including sytem level and user creation and deletion.

Is there a simple work around for this?

Otherwise it is the perfect solution for our needs.

Thanks.

tobychui commented 6 months ago

Well the user can still access the html files (front-end) of the modules. However, the agi runtime scope will block the user access to backend if the module is excluded from the user access module list, which is by design.

The same goes with system settings. The html file are accessible but the user will not be able to load data / or interact with it. Some optimization can be done here for sure but it is not in high priority.

tobychui / arozos