How to deactivate plugins?

[KonradHoeffner]

I want to deactivate loading the plugins in tenforce/docker-virtuoso:latest but none of the following approaches work, what is the correct way to do this?

FROM tenforce/virtuoso:latest
# This will throw an error
ENV VIRT_Parameters_Load1=
# Any of those lines has no effect at all
RUN ["sed", "-i", "s|^Load|;Load|", "/data/virtuoso.ini"]
RUN ["sed", "-i", "s|^Load|;Load|", "/virtuoso.ini"]     
RUN ["sed", "-i", "s|^Load|;Load|", "/usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso.ini"]             
# Just for testing, also no effect
RUN rm /virtuoso.ini    
RUN rm /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso.ini

The problem seems to be that Virtuoso is always autoregenerating the virtuoso.ini, but any virtuoso.ini that I find in the image via locate seems to be the wrong one.
While ENV VIRT_... allows to overwrite values in virtuoso.ini, I don't see a way to unset a value.

Also, the virtuoso.ini in the root of this repository doesn't have Load1...4 enabled but the one in the image does have it, even thought the file hasn't changed in many months.

[KonradHoeffner]

P.S.: After further research, the problem seems to be that the docker cache will restore the layer after each RUN command, so that my changes have no effect. I could create a wrapper script around virtuoso.sh that that changes the ini beforehand but is there a less convoluted alternative?

[TallTed]

I cannot offer much help with the tenforce image, but....

We (OpenLink Software, producers of Virtuoso) have our own Docker images, which are generally recommended over third-party images, including those from tenforce.

We also provide a Virtuoso Docker guide (titled and written primarily for Enterprise Edition, but generally applicable to VOS as well, with minor adjustments) which includes pointers on making your configuration and database files persist through Docker restarts.

[langens-jonathan]

Hey Konrad,

I don't know which plug in you need to disable. I suspect the reason you won't be able to disbale the plugin is because in our image we use RUN to do the entire compilation in one go. You can see that line here: https://github.com/tenforce/docker-virtuoso/blob/master/Dockerfile#L16

Feel free to make a fork and submit an MR with the plugin you want disabled removed from that line. If you don't want to go through the hassle, you can also just clone the repository and update that line locally. If you run 'docker build -t virtuoso .' in the root folder of the project. Then you should be able to include 'image: virtuoso' in any of your docker-composes (or execute 'docker run virtuoso') on that machine.

Alternatively, if you can tell us which plugin you would like to have disabled, we can see if we can update the repository to offer that option.

When it comes to persisting data and configuration, that shouldn't be an issue with the image as is.

[KonradHoeffner]

@langens-jonathan: Hello Jonathan,

I want to disable all plugins because I think I need none of them and they produce too much logging output at startup as I have a large docker-compose file and I try to reduce the logging output of each container in order to find problems more easily. Also I want to minimize startup time and resource usage. Making a pull request would be no problem at all for me, as that would just entail putting a semicolon in front of all the plugin statements in virtuoso.ini, however I do not want to break existing installations of other users.

[KonradHoeffner]

@TallTed: Thanks for the clarification! I thought tenforce was also an official virtuoso publisher, because the docker image has 500K+ downloads on dockerhub. Does this mean the tenforce-image is optimized for the tenforce company use cases and the official openlink image is better suited for a more general use case not related to tenforce? I will read the Virtuoso Docker guide and try switching to the official image. However what I like about the tenforce image is:

1. There is a GitHub repository where I can look into the Dockerfile, so I can see which distro it is based on to more easily align my different base images in a docker-compose file and for easier debugging and extensibility. The openlink image does not seem to have a publicly available source repository or is that just not shown on the docker hub page? I couldn't find a repository with the Dockerfile at https://github.com/openlink either, and https://github.com/openlink/virtuoso-opensource does not seem to contain a Dockerfile.
2. The tenforce container documents a way to automatically load quads from files on the first startup. However based on Docker image with virtuoso and loaded data openlink/virtuoso-opensource#995 it seems like that is possible there as well documentation coming soon.

[langens-jonathan]

Hey @KonradHoeffner, if you don't need any of the plugins then it might be better to use the official image. For the loading of the quads you could use/copy our initialization script. https://github.com/tenforce/docker-virtuoso/blob/master/virtuoso.sh.
We would also welcome a PR though, but then I think we would build it under a version tag that indicates no plugins were loaded.

@TallTed Thanks for the answers :) We would also welcome using the official image. I think for us the main reason not to is because plugins in virtuoso need to be added at compile time. In the official images everything is already compiled and so they have no support for plugins.

[TallTed]

@KonradHoeffner --

I thought tenforce was also an official virtuoso publisher, because the docker image has 500K+ downloads on dockerhub. Does this mean the tenforce-image is optimized for the tenforce company use cases and the official openlink image is better suited for a more general use case not related to tenforce?

Their high download numbers are largely because tenforce published their initial docker images some time before we first published ours. (Note that our official VOS 7 image now shows 500K pulls, even with tenforce's head start!)

I cannot speak to their expected usage scenarios relative to ours, but certainly we could make adjustments in what we provide if there is sufficient interest.

@langens-jonathan, @KonradHoeffner -- We should be able to come to a convergence on these, if you would please open issues on the Virtuoso repo for your respective needs.

I should note that the source for some of our plugins has not been updated in some years, due to apparent lack of user interest, and though built, they may not function as desired. Clear user interest/need would be a strong incentive for us to bring those plugins back up to speed.

@pvk -- Can you provide any insight on the Dockerfile @KonradHoeffner is looking for?

[KonradHoeffner]

@TallTed: Sure! I created an issue with my use case at openlink/virtuoso-opensource#996.