[
https://issues.apache.org/jira/browse/JENA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061781#comment-15061781
]
Joachim Neubert edited comment on JENA-1101 at 12/17/15 9:42 AM:
-----------------------------------------------------------------
Sorry for not being clear enough: I don't want to suggest to build RPM or dpkg
packages for Fuseki. This would require lots of knowledge and (one-time and
repeated maintenance) effort, and the advantages wouldn't justify that.
My suggestion is to factor out the conf hierarchy from the runtime files.
You're right in that they are installation-specific. However, FHS does not put
everything which is application-specific under {{/etc}}: Cache files would go
to {{/var/cache/fuseki}}, runtime system database files to something like
{{/var/lib/fuseki/system}}, user databases the same.
Again, I do not suggest to adopt this layout for Fuseki. But the current state
(default for .war installations) pollutes the {{/etc}} filesystem with data
that doesn't belong there. And that is not a purely academic question: Backup
software would utter warnings about files changed during backup, the size of
large user databases using the default location would blow up any expected size
for the {{/etc}} hierarchy, and probably similar issues. Any security measures
prohibiting arbitrary changes of files in /etc wouldn't work properly. By
factoring out a clean {{fuseki/conf}} ($FUSEKI_CONF) hierarchy in parallel to
the remaining {{fuseki/run}} ($FUSEKI_BASE, perhaps for clarity better renamed
to $FUSEKI_RUN) hierarchy this could be solved. Everything else could be left
to the user, perhaps, as you suggest, guided by examples for different distros.
I could contribute here for Centos.
Problem remains where to put the default for $FUSEKI_RUN in .war installations,
if this should not go into {{/etc/fuseki}}. I'll try to come up with a
suggestion for this, yet that may take a bit of time, since I'll have to give
the current June-2015 edition of FHS a closer look.
was (Author: jneubert):
Sorry for not being clear enough: I don't want to suggest to build RPM or dpkg
packages for Fuseki. This would require lots of knowledge and (one-time and
repeated maintenance) effort, and the advantages wouldn't justify that.
My suggestion is to factor out the conf hierarchy from the runtime files.
You're right in that they are installation-specific. However, FHS does not put
everything which is application-specific under /etc: Cache files would go to
/var/cache/fuseki, runtime database files to something like
/var/lib/fuseki/system, user databases under the same location.
Again, I do not suggest to adopt this layout for Fuseki. But the current state
(default for .war installations) pollutes the /etc filesystem with data that
doesn't belong there. And that is not a purely academic question: Backup
software would utter warnings about files changed during backup, the size of
large user databases using the default location would blow up any expected size
for the /etc hierarchy, and probably similar issues. Any security measures
prohibiting arbitrary changes of files in /etc wouldn't work properly. By
factoring out a clean fuseki/conf ($FUSEKI_CONF) hierarchy in parallel to the
remaining fuseki/run ($FUSEKI_BASE) hierarchy this could be solved. Everything
else could be left to the user, perhaps, as you suggest, guided by examples for
different distros. I could contribute here for Centos.
Problem remains where to put the default for $FUSEKI_RUN in .war installations,
if this should not go into /etc/fuseki. I'll try to come up with a suggestion
for this, yet that may take a bit of time, since I'll have to give the current
June-2015 edition of FHS a closer look.
> 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)
