But, the welcome page config (https://github.com/rstudio/shiny-server/tree/master/samples) need to
be stored in /srv/shiny-server for this welcome display to happen.
On 2022-04-27 21:40 +0530, Nilesh Patra wrote:
Hi All,
But, the welcome page config (https://github.com/rstudio/shiny-server/tree/master/samples)
need to be stored in /srv/shiny-server for this welcome display to happen.
(Note that I do not want to patch code to change the default behaviour here.)
Why not? This is what distro packages do - make sure things are installed in sensible places.
And patching a path is nice and simple (although you might also have to patch some docs to match).
I'm not sure what the right path is. The default webserver path in debian
has been /var/www/html/ for decades so I'd use that, but you might
have reasons to make it /var/www/shiny-server instead if you want shiny-server to be co-installable with other web-servers, and serve different stuff?
Following FHS 3.0 is required by Debian Policy, and it says that "no
program should rely on a specific subdirectory structure of /srv
existing or data necessarily being stored in /srv".
So if I understand the situation correctly, leaving the package to
depend on filesystem path /srv/shiny-server is a violation of Debian
Policy and needs to be fixed,
either by avoiding that code (installing
it only as example files) or patching, or convincing upstream to change default path.
On Wed, Apr 27, 2022 at 06:10:37PM +0100, Wookey wrote:
On 2022-04-27 21:40 +0530, Nilesh Patra wrote:
But, the welcome page config (https://github.com/rstudio/shiny-server/tree/master/samples) need
to be stored in /srv/shiny-server for this welcome display to
happen.
(Note that I do not want to patch code to change the default
behaviour here.)
Why not? This is what distro packages do - make sure things are
installed in sensible places.
And patching a path is nice and simple (although you might also have
to patch some docs to match).
No, sorry - that'd be a bit too much delta here, meaning shiny-server
would be able to serve from two loc (I do not want that) As a
distribution I do not want to be doing things completely orthogonal
from the way upstream does things.
Essentially if someone has a techincal way/solution to bypass this; or
if someone on the list has had experience of working on a package that
had similar reqs as shiny-server, it'd be nice to know what they did
for their package.
On 4/27/22 12:57, Nilesh Patra wrote:
I am looking for more opinions.
Patch every instance of /srv/shiny-server to /var/lib/shiny-server. The
admin can customize from there.
From FHS §5.8.1,
This hierarchy holds state information pertaining to an application
or the system. State information is data that programs modify while
they run, and that pertains to one specific host. Users must never
need to modify files in /var/lib to configure a package's operation,
and the specific file hierarchy used to store the data must not be
exposed to regular users.
So, I think this suggestion of storing shiny-server (presumably
modifyable) configurations and served data in /var/lib/shiny-server
would violate policy.
Patch every instance of /srv/shiny-server to /var/lib/shiny-server.
The admin can customize from there.
From a user's perspective it would be much clearer if Debian could dothe same, in my opinion, so all of this existing and distributed
On Wed, Apr 27, 2022 at 07:42:29PM +0200, Jonas Smedegaard wrote:
Following FHS 3.0 is required by Debian Policy, and it says that "no program should rely on a specific subdirectory structure of /srv
existing or data necessarily being stored in /srv".
So if I understand the situation correctly, leaving the package to
depend on filesystem path /srv/shiny-server is a violation of Debian
Policy and needs to be fixed,
This was the whole point of my email, and it is the reason I started
this email thread in the first place.
I would have gone with installing it in /srv w/o seeking advice if it were not a violation.
either by avoiding that code (installing
it only as example files) or patching, or convincing upstream to change default path.
Yes, this was discussed in just the previous conversation (w/ me and wookey) I am looking for more opinions.
Essentially if someone has a techincal way/solution to bypass this; or if someone on the list
has had experience of working on a package that had similar reqs as shiny-server, it'd be nice to
know what they did for their package.
Best, Nilesh
The issue is that the documentation, samples and all of the upstream
online documentation, e.g. https://support.rstudio.com/hc/en-us/articles/219002337-Shiny-Server-Quick-Start-Host-a-directory-of-applications
(or on third party sites like Stack Overflow), refer to
/srv/shiny-server as the default location for hosting. I doubt
upstream would want to change all of that without a strong reason.
From a user's perspective it would be much clearer if Debian could do
the same, in my opinion, so all of this existing and distributed documentation and support still applies to new users of the Debian
version. Is there a technical solution to enable this, e.g. post installation, that satisfies Debian's requirements?
We do try to hold the line on not installing files in /srv and not
requiring any specific layout of /srv because the FHS is pretty explicit
that the choice of directory layout in /srv is entirely up to the local administrator and distributions should not be messing with it.
The default/expected behaviour just after package install is that as
soon as the user starts it and visits (talking about local setup here) localhost:<port-it-binds-to> they should be seeing a welcome page.
Thank you for the explanation, and thanks for the history and pointer
towards tftp. Looks like you remembered correctly (https://lists.debian.org/debian-devel/2020/02/msg00197.html). I installed tftpd-ahp. Interestingly, after all that discussion, it still does create a directory /srv/tftp which is its default served directory, like the upstream shiny-server behaviour.
Best,
Eric
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 156:06:21 |
| Calls: | 10,384 |
| Calls today: | 1 |
| Files: | 14,056 |
| Messages: | 6,416,468 |