ii virtualmin-config 7.0.16 all Configure a system for use by Virtualmin
ii virtualmin-core 7.0.0 all Metapackage for core Virtualmin dependencies.
ii virtualmin-lamp-stack 7.0.4-1 all Metapackage for Virtualmin LAMP Stack.
ii webmin-virtual-server 7.10.0.gpl-1 all Webmin module Virtualmin Virtual Servers
I added a port to be opened.
I saw the small “Apply” button thinking that it would apply the changes. No such luck. It didn’t do anything. As a last resort I did a Reload FirewllD and that made the change.
I just want to document this in case someone else thinks that the apply button is the way to change the rules. Since I didn’t know the definition of “the rules that were permanently created” I didn’t want to destroy what I had added. As far as I knew I hadn’t permanently created anything.
When changing some configuration of FirewallD, or Webserver (Apache or Nginx) or even PHP or indeed the database server it is frequently good advice to stop and restart the service.
You will often find that configurations are only applied once when the service is started.
I do understand that and routinely restart services when I make config changes, however when I see a selection entitled “Apply” it leads me to believe it. I have no idea what that does, but I do know it doesn’t do what the term “Apply” suggests. As I mentioned, the word “Permanent” in the description for the restart button gave me pause. I believe the description needs to be a bit more description, such as “Apply the changes”
English, but I missed the point. I did that. That put my new port in the table but it didn’t actually open the port until I did the “Reload firewall” I hesitated because I didn’t know what rules were “permanently created” . Because of that statement, I believed there was something else that I had to do to create them permanently and that if I didn’t then the restart might ignore my changes.
Perhaps I could have been a little clearer here, configuration rules are only permanently applied when a service is *re-*started. this is usually due to the fact that services are usually compiled and run as processes and therefore have to be stopped before they can be loaded with new configuration which are usually written in scripts (think of the *.ini *.cfg files - these scripts are in human readable language) the user interface just provides a way to edit and save these script’s changes. Stopping and restarting the process allows those saved changes to be loaded compiled and re-executed as the changed service.
Unless the service has a reload function which as the name suggests reloads the configuration which in turn implies that you don’t need to use the stop and start functions of the service. This assumes the service is coded correctly to implement a reload.
