[
https://issues.apache.org/jira/browse/JENA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15065338#comment-15065338
]
Joachim Neubert commented on JENA-1101:
---------------------------------------
What made me think that {{/etc/fuseki}} is a mandatory for webapps, is this
line:
??When run in a web application container (e.g. Tomcat, Jetty or other webapp
compliant server), FUSEKI_BASE will be /etc/fuseki.??
in https://jena.apache.org/documentation/fuseki2/fuseki-layout.html (below the
first table on defaults).
Thank you very much for your hint that a differing setting of FUSEKI_BASE in
the tomcat environment should be respected. I have verified that, and it solves
my immediate problem in preparing a fuseki/tomcat installation on one of our
production servers.
However I still think the default location should be fixed (and I very much
hope not to annoy you): FHS states quite stricly that only static files should
go into {{/etc}}, making this even more clear by
[mentioning|https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html]:
"{{mtab}} does not fit the static nature of {{/etc}}; it is excepted for
historical reasons."
While distros may differ in the most common locations for packages and their
runtime files, I've seen no disagreement on this nature of {{/etc}}.
The rationale why I suggested {{/opt}} as a base over something under
{{/usr/local}} is that the {{/usr}} filesystem [is
supposed|https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html#purpose18]
to contain read-only data, too. If you have to select a single root for a
package, {{/opt}} seems to fit best (putting aside the {{/var/opt}} and
{{/etc/opt}} recommendations, as everybody agrees to do).
In my eyes, a change of the default of $FUSEKI_BASE for webapps from
{{/etc/fuseki}} to {{/opt/fuseki/run}} would not necessarily mean to break
existing deployments: Wouldn't it be possible to check if a
(container-writable) directory {{/opt/fuseki/run}} exists, and otherwise, for
backward compatibility, check for {{/etc/fuseki}}, perhaps uttering a warning
in the log? For me, that would seem in line with JENA-1099 and your care for
compatibility. The new default could be announced, and {{/etc/fuseki}} could
mentioned as deprecated in the docs (to be removed with some future major
release). And after all, it would be easier to change now, better than later
when more webapp deployments have adopted or somehow worked around
{{/etc/fuseki}}.
I'd be happy to submit a patch for the doc page (after having learned how to do
it properly :)).
> 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)
