Hey all,
I am aware that Webmin does the âsystem wide servicesâ configuration in the sense of âroot levelâ while Virtualmin uses those ( and some more ) services to provide virtual hosting on those services. to the best of my awareness, the both are somewhat integrated in the sense of them calling âapi styleâ commands on each other to get things done. Some of the modules do direct edits on files to change the working of the setup. I think i know which option most of them use.
As of today i have been unable to reproduce the issue, although i had it happen on two different systems, one virtual, one physical. given these systems are on fully separated physical machines, i rule out hardware failures
the virtual system runs as a slave nameserver, virtualmin is installed though only runs a single domain, the default domain so ssl and such are nice and in check.
the physical server is used as a vm hypervisor, once again virtualmin is installed to keep ssl and such in check from a single default domain.
both systems are running some low level loads, are hardly ever logged into by a human other then to do some updates if webmin sends alerts for them. they have been running mostly fine since beginning of 2019 like that. The nameserver gets its rpc routines called for dns from around 10 remote systems that are actually hosting content.
given that both the config file and the localips file are timestamped the exact same once a system breaks, it leads me to conclude it has something to do with the network stack, or a change picked up by web / virtualmin. Given the contents of the config file, and virtualmin breaking on itâs corruption, i assume itâs mainly a file for virtualminâs use. there are no software management packages or anything else that could touch those files other then web / virtualmin itself.
given that the 2 files mentioned before seem to mostly relate to networking. i looked back in the few notes i have made for myself. in both cases the only thing that has been done in the networking stack on both, is âa fixâ on the ipv6 sections of the machines. the ns had an attempt to modify ipv6 into a properly working state as i want to get ipv6 ready / enabled. The physical host was fased out and replaced, I had started reshaping itâs networking to fit into the new style network layout i want. in that process i have renamed itâs wan br0 to br-wan06. while i renamed the interface config file, i forgot to rename the route6-br0 config file, so v6 was not working properly.
In both cases the problem showed up in virtualmin after installing updates ( via webmin ) and then follwing up with a reboot to apply the new updates. both files have a timestamp that is just a few seconds after the system booted up. and at that point virtualmin was broken, while before the reboot yet after the updates, the system was in a working state.
So yes given all the above, i think itâs virtualmin breaking itself over something that changed in the network stack and gets âconfusedâ somehow. I am suspecting it needs a certain pre-condition to appear just after the reboot is finished and web/virtualmin starts.
I will keep trying in the next few days to reproduce the problem as itâs not easy to figure out what is actually broken once virtualmin corrupts itâs config file. most of virtualmin just hangs or throws misleading errors. it took me a long while to figure out the config file was corrupted. by comparing the files and folders from my other virtualmin systems. thereafter it took me another while to figure out there was a file named last-config that can actually be used to restore to a working status.
Steven