Use separate args for dotnet publish commands
Original-merge: d260f30810
Merged-by: Joshua M. Boniface <joshua@boniface.me>
Backported-by: Joshua Boniface <joshua@boniface.me>
Remove mount and unmount permissions for jellyfin group from sudoers
Authored-by: Shadowghost <Ghost_of_Stone@web.de>
Merged-by: Claus Vium <cvium@users.noreply.github.com>
Original-merge: 9cebdfdec0
* Target net6.0
* Use new Enum.TryParse(ReadOnlySpan<char>) overload
* Replace RNGCryptoServiceProvider with RandomNumberGenerator
* ci - target net6.0 (#6594)
* Update deployment for dotnet6
* Use generic 6.0.x preview for CI
* Update direct dotnet download links
Co-authored-by: Bond_009 <bond.009@outlook.com>
In my setup I configured a different user. But updates keep "stealing" file permissions for my `$PROGRAMDATA $CONFIGDATA $LOGDATA $CACHEDATA` directories.
Reportedly `systemd-run --scope` still got killed by the service
manager; see #4615. The suspected cause is that `scope` units are run by
the `systemd-run` process itself and inherit the caller's execution
environment (see systemd-run(1)). To fix this, we use a systemd
`service` unit instead, which is run and managed by PID 1 - hopefully
this will isolate us sufficiently so that we don't get terminated along
with `jellyfin.service`.
systemd-run(1) runs `systemctl restart` in an isolated systemd unit
that is not subject to process termination as jellyfin.service is shut
down. We adjust the sudoers configuration for this new usage, removing
the old config, since restart.sh is the only user of the sudoers
policy.
Additionally we change `systemctl start` to `systemctl restart` since
there was a race condition where jellyfin.service was not fully
stopped by the time this ran, so `systemctl start` became a noop.
`systemctl restart` on the other hand works whether jellyfin.service is
stopped or not.
The at(1) hack (and the usage of `start` instead of `restart`) is left
in for other init systems since I cannot test on those systems, and
because I don't know of any systemd-run(1) equivalent (although it may
be a non-issue since alternate init systems do not keep track of daemon
children nearly as aggressively as systemd does).
It's used in the restart.sh script.
For Debian, this is a Recommends because virtually everyone will need
this (default APT policy is to install recommended packages so this
works ok), but technically you can configure the server to run as root
and then you wouldn't need it.
For Fedora... frankly I got confused by their Weak Dependencies etc. so
I just made it a hard dependency.
Some environments, like system containers, have no reason to have
sudo(8) installed. In these environments restart.sh will silently fail
because /usr/bin/sudo does not exist to execute, so test that sudo
exists and don't try to use it otherwise.
Note also that hardcoding sudo's path is wrong: it can be installed in
other places. On FreeBSD, for example, it is /usr/local/bin/sudo when
installed from ports.
The old code was wrong because e.g. systemd can be *installed* on the
system, but not actually used as PID1. In that case we would pick
`systemctl`, but it wouldn't actually work because PID1 was some other
init system.
Should solve the occasional bugs with the restart in the WebUI.
Sometimes the service stops and then doesn't start again; this will run
an explicit start action afterwards. If this doesn't fix it I'm certain
there would be more tweaking that can be done.
After removal of the symlink target file "/usr/lib/jellyfin/bin/jellyfin", file existence check on the symlink "[[ -f /usr/bin/jellyfin ]]" returns false. As a result the symlink is left in place on package purge. The correct check would be "[[ -L /usr/bin/jellyfin ]]", but since it could be a file in cases, e.g. manual fix on file systems with no symlink support or for any other reason, it is easiest to use "rm -f" to assure that it is removed in both cases and not return false even if it does not exist at all.
Additionally this fixes a typo on upstart script check.
Signed-off-by: MichaIng <micha@dietpi.com>
It's been long enough that this is no longer an issue. We still conflict
on the ports 8096 and 8190, but this will simply result in a failure to
start; allow users to get themselves into that situation if they wish.
Fixes the incorrect dependency handling from 10.6.0, which was missing
the Replaces and Breaks entries on jellyfin-server. Thus apt would
complain about /etc/default/jellyfin being in two packages and fail to
upgrade. With this configuration, I've verified that apt now handles
this situation properly.
