Having problems installing Virtualmin (via the install.sh file) on a fresh Godaddy Centos 7 (centos-release-7-3.1611.el7.centos.x86_64) VPS (OpenVZ version 3.10.0-042stab094.8) server.
At server start (not installed anything, just ran yum update) Iptables has an issue with missing iptables modules. For example state is missing so the default /etc/sysconfig/iptables file throws an error out on the commit line (line 14). I got Godaddy to enable the missing modules and iptables was working, but I couldn’t get port 10000 open after installing Virtualmin : this really threw me off and went down the wrong path to fix things.
Destroyed and Rebuilt the server to start again and the idiots at Godaddy hadn’t made the iptables module change survive a rebuild, so was back with the line 14 error related to the iptables state module missing!
Decided to try anyway with a view to changing the Webmin port to rule out an issue with port 10000.
Masked iptables/ip6tables and installed Virtualmin with no errors reported, but port 10000 appeared to be closed (in hindsight I don’t think it was), port 20000 was open and Usermin worked.
Changed the Webmin port and added a new port rule to the /etc/sysconfig/iptables which was having an impact despite masking iptables. Webmin still didn’t work (via a browser), at this point realized Webmin wasn’t actually running on the server (HUGE DOH!!! moment).
Tracked down why Webmin wasn’t running to the “ipv6=1” line in “/etc/webmin/miniserv.conf” : changed it to “ipv6=0” and Webmin started (after a reboot) and the new port was open. In hindsight I’m assuming port 10000 would have worked had I made this “ipv6=1” line change: Webmin has to run for the Webmin port to be open (I’d assume the port would be open because there’s a rule in the iptables file, apparently not).
Logged into Virtualmin/Webmin and went through the Virtulmin setup and hit problems installing MYSQL (Mariadb) and named, had some errors related to the wrong group:owner set on these directories.
/var/run/mariadb/
/var/run/named/
Both were set to root:root, fixed with:
chown mysql:mysql /var/run/mariadb/
chown named:named /var/run/named/
or
chown mysql:mysql /run/mariadb/
chown named:named /run/named/
Mariadb and Named appeared to work: no virtualservers installed, but no error so looked good.
Dovecot wasn’t running, adding “listen = *” to dovecot.conf fixed the errors.
Thought everything was working, but after a reboot the directories “mariadb” and “named” had their group:owner set back to root:root and haven’t worked out how exactly to fix this issue?
Also seeing other permission denied errors in the logs:
Jan 6 03:13:40 ip-###### systemd-sysctl: Failed to write ‘0’ to ‘/proc/sys/net/bridge/bridge-nf-call-iptables’: Permission denied
Jan 6 03:13:40 ip-###### systemd-sysctl: Failed to write ‘16’ to ‘/proc/sys/kernel/sysrq’: Permission denied
Jan 6 03:13:40 ip-###### systemd-sysctl: Failed to write ‘1’ to ‘/proc/sys/kernel/core_uses_pid’: Permission denied
Jan 6 03:13:40 ip-###### systemd-sysctl: Failed to write ‘0’ to ‘/proc/sys/net/bridge/bridge-nf-call-arptables’: Permission denied
Jan 6 03:13:40 ip-###### systemd-sysctl: Failed to write ‘0’ to ‘/proc/sys/net/bridge/bridge-nf-call-ip6tables’: Permission denied
Not looked into those in detail yet: the files exist and all are set to root:root.
Can you see anything in the steps above why the directories “mariadb” and “named” (and presumably others: all directories under /run/ are root:root, under my other Virtualmin servers they aren’t all root:root) would start with the wrong owner:group set?
And how do I stop a reboot resetting them back to root:root?
My first time working with Centos 7, my other Centos 6 Virtualmin VPS servers were a doddle to install compared to this 
Thanks
David