[
https://issues.apache.org/jira/browse/JENA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15062623#comment-15062623
]
Joachim Neubert edited comment on JENA-1101 at 12/17/15 7:32 PM:
-----------------------------------------------------------------
In the case of a Fuseki installation as a service, you are right - I can use
symlinks to create almost arbitrary layouts, with considerable effort though if
I want to separate configuration and other runtime files completely.
However, in case of the Webapp installation, it seems to be mandatory (as I
understand the
[docs|https://jena.apache.org/documentation/fuseki2/fuseki-layout.html]) to
have the complete configuration _and_ runtime environment physically or
symlinked under {{/etc}}.
This not only contradicts the Linux filesystem standards. An installation in
{{/etc}} requires root access, and I'm quite sure that many if not most
sysadmins of production systems (for sure in my current and prior institution)
will not allow {{/etc}} directories (symlinked or not) which have at least in
parts to be writable by the user under which the web container runs.
To fix this particular issue, it would be sufficient to let $FUSEKI_BASE for
Webapps point outside {{/etc}}.
The most reasonable location for $FUSEKI_BASE seems to be {{/opt/fuseki/run}}.
{{/opt}} is intended for "Add-on application software packages", where "all
data required to support a package on a system must be present within
{{/opt/<package>}}". [By the
book|http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html],
configuration for a package should go to {{/etc/opt/<package>}} and variable
files should go to {{/var/opt/<package>}}. This would however mean more
"hunting in the filesystem", as you put it, and I haven't seen this latter rule
implemented by packages in the wild.
In my eyes, this proposed change would be maximal compatible with the current
layout (any more complicated), and avoid a hard-coded location which
contradicts the standard and widely expected use of {{/etc}}.
The question, if configuration should be separated from other runtime files,
should perhaps be treated in a separate Jira issue.
was (Author: jneubert):
In the case of a Fuseki installation as a service, you are right - I can use
symlinks to create almost arbitrary layouts, with considerable effort though if
I want to separate configuration and other runtime files completely.
However, in case of the Webapp installation, it seems to be mandatory (as I
understand the
[docs|https://jena.apache.org/documentation/fuseki2/fuseki-layout.html]) to
have the complete configuration _and_ runtime environment physically or
symlinked under {{/etc}}.
This not only contradicts the Linux filesystem standards. An installation in
{{/etc}} requires root access, and I'm quite sure that many if not most
sysadmins of production systems (for sure in my current and prior institution)
will not allow {{/etc}} directories (symlinked or not) which have at least in
parts to be writable by the user under which the web container runs.
To fix this particular issue, it would be sufficient to let $FUSEKI_BASE for
Webapps point outside {{/etc}}.
The most reasonable location for $FUSEKI_BASE seems to be {{/opt/fuseki/run}}.
{{/opt}} is intended for "Add-on application software packages", where "all
data required to support a package on a system must be present within
{{/opt/<package>}}". [By the
book|http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html],
configuration for a package should go to {{/etc/opt/<package>}} and variable
files should go to {{/var/opt/<package>}}. This would however mean more
"hunting in the filesystem", as you put it, and I haven't seen this latter rule
implemented by packages in the wild.
In my eyes, this proposed change wouldn't be more complicated than the current
layout, and avoid a hard-coded location which contradicts the standard and
widely expected use of {{/etc}}.
The question, if configuration should be separated from other runtime files,
should perhaps be treated in a separate Jira issue.
> Fuseki filesystem layout and Linux FHS
> --------------------------------------
>
> Key: JENA-1101
> URL: https://issues.apache.org/jira/browse/JENA-1101
> Project: Apache Jena
> Issue Type: Improvement
> Affects Versions: Fuseki 2.3.1
> Reporter: Joachim Neubert
>
> When it comes to filesystem layout, the Java/Tomcat/Webapps world differs
> quite fundamentally from the Linux world: Whereas for Tomcat or Fuseki it is
> quite normal to have all files under a common root directory, the [Linux
> Filesystem Hierarchy
> Standard|https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard] (which
> is followed by most distributions) provides multiple roots for application
> files:
> Configuration goes to /etc, read-only files to /usr, variable files to /var
> (./log, ./cache etc.). To give you a better idea what this means in practice,
> I add the layout of the tomcat installation by Centos 7 RPM as an example.
> From a linux sysadmins point of view, this makes it easy to know where to
> find stuff without any special knowledge of the application, and to
> generalize tasks like backup (e.g. exclude all application cache files on the
> system).
> On the other hand, this means considerable more work, if you have to cover
> systems outside the Linux world too. Things may get even more complicated by
> remaining differeces between distributions and SElinux policies.
> So I don't suppose FHS compatibility is an realistic option for Fuseki.
> Yet, the current handling of mapping $FUSEKI_HOME/run to /etc/fuseki, with
> the whole bunch of assorted runtime files, feels profundly wrong. According
> to FHS, I would expect something like
> {noformat}
> etc/
> fuseki/
> config.ttl
> shiro.ttl
> conf.d/
> service1.ttl
> ...
> {noformat}
> and all the other stuff elsewhere.
> So I wonder if it would be possible to put the config hierarchy above under
> a, say, $FUSEKI_CONF root, which defaults to /etc/fuseki in the .war
> installation, and to $FUSEKI/conf otherwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
