Wow, I guess your admins must have caused you a pain in the neck :).
You could also try chmod -w on openfire/conf/available-plugins.xml. That file contains Gateway entry, so you would want to delete that line. When you’re done, restart openfire. The problem with this method is that you’ll never get the updated list of available plugins, and perhaps you don’t bother either .
My admins have not caused me any headaches yet and I hope to keep it that way.
Chmod-ing the available-plugins.xml and making it read-only is a good idea that I had not thought of. I could manually push a modified available-plugins.xml with the rest of my system updates when a new available-plugins.xml becomes available.
Not to get too technical, but my idea/work-around/hack is as follows:
Put a modified version of available-plugins.xml on my webserver
Write a bash script that uses wget to fetch the modified available-plugins.xml and set it to read-only
Run the bash script as a weekly cron job
This allows me to remove any plugins that I do not like and still get updated lists.
By the way, if my users run the IM gateway plugin it will cause the system to be doing things that are against the law. Per Federal Communications Commission rules, Part 97. These infractions commonly carry fines of thousands of dollars. See The Outernet Project for more details.
h5. Not to get too technical, but my idea/work-around/hack is as follows:
Put a modified version of available-plugins.xml on my webserver
Write a bash script that uses wget to fetch the modified available-plugins.xml and set it to read-only
Run the bash script as a weekly cron job
Well… on the second thought, I don’t think any of these would work because once Openfire fetched (on exact time, daily) the latest update it will cache it. The file is only useful (read) when openfire starts. You might want to verify this from the source code. So, the best way (perhaps the only way without restarting Openfire) could be to hack Openfire source code
You might be able to go about it a different way as well -> after installing or upgrading openfire, go into openfire/src/plugins/admin/webapp/WEB-INF, edit web.xml. and delete:
That’ll make the web interface for adding new plugins go away… forcing folk to have to have local access to the server to install new plugins (while retaining the ability to update existing plugins)
I will warn you that in 3.4.0 I added the ability to upload plugins through the web interface via a simple form. (plugins that aren’t on the available plugins page) But it’s not quite as trivial as hitting the available plugins page and outright seeing what’s all available.
to remove the plugin interface altogether. (I mean the link will still be there, but it won’t function) Then you can limit to only server access people being able to do -anything- with plugins.
I think this is just one of the situations in which different levels of admin access are deemed necessary. Access to what one can do with plugins could have easily been achieved if the admin console were designed from ground up to be object oriented and as MVC as Clearspace. Perhaps the core Java and Web programmers haven’t found a way to join forces yet .