systemd or sysvinit for .NET Core app?

Chat about Linux in general
Post Reply
Translucency
Level 1
Level 1
Posts: 11
Joined: Thu Jan 03, 2019 9:23 pm

systemd or sysvinit for .NET Core app?

Post by Translucency » Sat Jan 05, 2019 12:20 pm

Hello, all.

Some Context:
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.

The Question:
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.

Thanks!

rene
Level 10
Level 10
Posts: 3282
Joined: Sun Mar 27, 2016 6:58 pm

Re: systemd or sysvinit for .NET Core app?

Post by rene » Sat Jan 05, 2019 6:44 pm

SysVinit is basically obsolete and features in the main distributions only in a backwards compatibility sense (Slackware would be the biggest straggler; Gentoo with OpenRC on top). You should concentrate on systemd that is.

/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...

Translucency
Level 1
Level 1
Posts: 11
Joined: Thu Jan 03, 2019 9:23 pm

Re: systemd or sysvinit for .NET Core app?

Post by Translucency » Fri Jan 11, 2019 8:43 pm

Thanks!

I got this working using systemd. :)

In case you're interested: https://github.com/jay-rad/doxm

rene
Level 10
Level 10
Posts: 3282
Joined: Sun Mar 27, 2016 6:58 pm

Re: systemd or sysvinit for .NET Core app?

Post by rene » Sat Jan 12, 2019 2:22 am

Translucency wrote:
Fri Jan 11, 2019 8:43 pm
In case you're interested: https://github.com/jay-rad/doxm
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
after populating serviceConfig in the foregoing read. While I would personally probably advise to just have the service file around as an actual file and simply copy it into place, fair enough I guess if you desperately want to keep the script self-contained. But, and although I take it from context on line 1 and 2 that this script is being run with stdin connected to actual user input, what's that foregoing sudo nano /etc/systemd/system/doxm.service doing 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
you are downloading and sourcing the dotnet-install.sh script, a script which supposedly needs root privileges to run, but you are running curl through sudo there; are downloading as root rather than executing it as such, which means that you are supposedly launching the entire DOXM_Server_Install.sh script with sufficient privileges for the dotnet-install.sh script already. So what's with all the sudo's in the first place?

Just below that you are then seemingly entering into an interactive root shell with sudo -s which has me wonder the same things as for the nano invocation.

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 $*"
(in which you can leave out the "$*" if you don't pass any arguments to the script). This would get rid of all sudo's except that one itself.

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 sudo -s and nano invocations. Might just be missing something; quite unaware of the general "dotnet environment".

Translucency
Level 1
Level 1
Posts: 11
Joined: Thu Jan 03, 2019 9:23 pm

Re: systemd or sysvinit for .NET Core app?

Post by Translucency » Sat Jan 12, 2019 2:52 am

Hi!

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!

Thanks again.

Translucency
Level 1
Level 1
Posts: 11
Joined: Thu Jan 03, 2019 9:23 pm

Re: systemd or sysvinit for .NET Core app?

Post by Translucency » Sat Jan 12, 2019 2:59 am

I just realized the first two lines probably need an explanation.

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.

rene
Level 10
Level 10
Posts: 3282
Joined: Sun Mar 27, 2016 6:58 pm

Re: systemd or sysvinit for .NET Core app?

Post by rene » Sat Jan 12, 2019 3:56 am

Ah, that makes more sense now. Fairly little to critique for the new script, but:

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
If the parameter to --path can conceivably contain whitespace --- it supposedly can --- you would want to quote $2 there; i.e., have it be "$2". Same for $HostName, although it can supposedly not contain whitespace. Indentation of the above is a trivial comment.

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 -f rather than rm -rf.

[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.service and 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.

Post Reply

Return to “Chat about Linux”