I built a self-hosted, cross-platform remote desktop and remote terminal solution, which can be found at https://doxm.app and https://github.com/jay-rad/doxm. It's similar to TeamViewer, where the client service maintains a persistent socket connection with the server so remote sessions can be started without opening any firewall rules.
I'm finally getting around to building out all the pieces for the Linux client. It's a self-contained .NET Core app that works on most distros, and it will be installed via a shell script.
I'm new to Linux (I tried Ubuntu for a while and didn't like it), so I'm picking things up as I go. I'm also moving my websites and app services from Windows servers to Linux VMs, so I'm trying to get more familiar before making the final cut-over.
Since my client app is distro-agnostic and self-contained, I want the install script to also work on any of the popular distros.
With that in mind, what would be the best way of installing the app as a daemon/service? So far I've looked at sysvinit (which appears to use scripts in /etc/init.d/) and systemd (which appears to use service configs in /etc/systemd/system/). Please correct me if I'm wrong on any of that.
/lib/systemd/system is the location for package-installed unit files; its /etc counterpart is for locally installed unit files (i.e., by the system administrator) and/or overrides of system ones.
I'd be tempted to advise looking into Flatpak, Snap or even AppImage packaging; distribution agnostic packaging formats in which you basically ship the application alongside its dependencies so as to sidestep issues of compatibility among N distributions. It might on the other hand not be a good match if you want/need daemon functionality...
I must say I seem to have a little trouble following along there. I see where you are creating the service file, https://github.com/Jay-Rad/DoXM/blob/ma ... Install.sh,
Code: Select all
echo $serviceConfig > /etc/systemd/system/doxm.service
sudo nano /etc/systemd/system/doxm.servicedoing there? You're launching an actual interactive editor? Am I just looking at a bit of temporary/debug code there?
Also, the use of sudo is a little weird. I.e., in the line
Code: Select all
sudo curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin
Just below that you are then seemingly entering into an interactive root shell with
sudo -swhich has me wonder the same things as for the
Other than those specific points a possible generally useful tip: if the sudo's are in fact required/wanted it seems you should launch the entire DOXM_Server_Install.sh script through sudo, not invoke the individual command in it through sudo. If actually launching through sudo is undesirable for some reason, a trick I myself moreover usually employ is having a script relaunch itself through sudo by starting it with
Code: Select all
[ $(id -u) -eq 0 ] || exec sudo "$0 $*"
But, that bit is general comment. I'm as said mostly wondering about all of the sudo's in the first place, seeing as how you apparently launch with sufficient privilege for dotnet-install.sh already, and most definitely about the seemingly interactive
nanoinvocations. Might just be missing something; quite unaware of the general "dotnet environment".
Thanks for the reply. Honestly, I forgot that script was even there and was being referenced in the readme. That's a different script than what I was working on recently. I was mostly pasting stuff into that as I was setting up my demo server manually. So yeah, that needs to be edited.
I'm very new to Linux. I was even more so a few months ago when I started putting the Linux stuff together.
The self-elevating trick there is really handy! I saved that snippet for later.
The interactive nano line was indeed some debug stuff I accidentally pasted in. And all the sudo's was my lack of understanding at the time.
The script I was putting together when I made this post is here: https://github.com/Jay-Rad/DoXM/blob/ma ... nux-x64.sh
That's the script that installs the service, which allows unattended remote control and remote PowerShell/Bash scripting. Please feel free to critique that one too!
The script is returned from a hyperlink that points to an API that requires authentication. The server's hostname and the user's organization GUID are placed into those variables as it's being served.
Code: Select all
if [ "$1" = "--path" ]; then echo "Copying install files..." cp $2 /usr/local/bin/DoXM/DoXM-Linux.zip else echo "Downloading client..." wget $HostName/Downloads/DoXM-Linux.zip fi
Only other thing that's tempting to comment on is the "Enter the username whose Xauthority file will be used. Note: This user will need to be logged in for the remote control session to work" bit, as a setup with a system-global service referring to a user-private resource seems potentially undesirable --- but I suppose that's actually fairly intrinsic to what this software in fact is/does. I haven't in fact looked at that part so please feel free to ignore.
Certainly you should ignore a comment to the effect of few Linux users not blinking upon seeing
rm -r -frather than
[EDIT] Oh, wait, what I thought of but then forget again... it's more generic to spell out the .service. I.e., say
systemctl enable doxm-client.serviceand same for
start. It's again not in fact important in this case but generally speaking different types of unit files may exist with the same name; foo.timer and foo.service being the most definite example. As such, it's best practice to specify the .service.