Failed to get security context of /etc/selinux/config

What is the exact version of CentOS? (Look in /etc/redhat-release)

This isn't anything to do with Virtualmin updates, but may be something with the new CentOS updates (I just saw a few hundred new packages show up on all of my CentOS 7 boxes, so I guess there's a new minor version). SELinux should be disabled during installation, so there's no reason SELinux should be complaining once it's turned off (sometimes it'll complain when we try to turn it off, if it's already off, though, but the error looks different than this). It's possible to run Virtualmin with SELinux enabled, with a few tweaks to a half dozen or so booleans, but it's a pain in the ass in ways that confuse users, so we still disable it.

Definitely don't start a new server on CentOS 6! If there's a problem with the new CentOS, I'll fix it, I'll just need to reproduce it. I did an install on CentOS 7 a few days ago that worked, but I haven't done one since all those new packages came out.

I've been able to reproduce it. I don't quite understand what's happening...it looks like a bug in one of the new packages (not ours). That file should have a context at the point where we're messing with it...so...it shouldn't give this error. And, I'm not sure it should give this error even if it doesn't have a context.

Yeah, after some testing, this is definitely a bug in one of those new packages. I won't be able to fix it. I'm not even sure I can workaround it, but I'm going to try a couple of things to avoid using sed (but we rely on sed quite a bit, so that'll be a problem...something else might be going wrong, too). Basically sed cannot modify files in /etc, which is wild. Among the new packages are updates to libselinux and libsepol (selinux policy), so I guess it's doing something bad.

So...we may have to hope Red Hat/CentOS rolls a fix for this soon. I will try copying the files we need to modify to a tmp dir and copying them back after modifying, but I have a vague feeling that won't work either (but if the problem is strictly with sed, it might).

I think I understand why it's happening, but not why that thing is happening. But, I think I can probably fix it or workaround it.

OK, got a workaround.

Install Virtualmin. Do nothing after installation; don't do the install wizard or anything like that.

Reboot.

Run the following command once rebooted:

This will probably get you going right. I haven't tested beyond this, though, and it's late, so I'm not going to be able to do much more.

The cause of the problem is that the bind package depends on selinux-policy (I don't know why), which seems to turn selinux on, even if it was disabled before installation. This seems very bug-like. This means that selinux is running but no files have security context information, which means operations that check the selinux context fail (no matter what state selinux is in...even if you disable it, it still fails). Rebooting seems to make it act reasonable again, though I don't quite understand why (I guess because SELinux is completely disabled rather than put into permissive mode).

So, this problem won't happen on a system that has selinux enabled when Virtualmin is installed (because files will have context info, and turning to permissive mode or disabled won't matter). But, if selinux is off, and that policy package gets installed, it seems to turn on selinux but without context info. I was also unable to run restorecon, so there's more than one problem with what's happening here. Definitely bug-like on the part of the package. I'll try to figure out a way to workaround this without a reboot, but as long as installed selinux-policy partially enables selinux when installed, I'm not sure it's possible, which sucks. Hopefully, it'll get fixed.

So...sed is seemingly the only thing broken by this problem, which is really weird, but it's good news, because we only use sed in two places, both of which are the things we're seeing fail here. I will roll new versions of install.sh and Virtualmin-Config tomorrow that replaces both of those uses of sed with a perl replacement.

In the meantime, the above workaround should work fine. I don't think anything else is broken, since I don't think there are any other sed uses.

I've checked in and released a fix for the install.sh, which you can get by downloading the install.sh again, but Virtualmin-Config (the Postfix error) will still be a problem. So, you'll still need to reboot and run that virtualmin config-system command I mentioned above. I'll fix that tomorrow when I'm not so tired.

I should have gone to sleep. I checked in a typo, so it would bail before finishing...so, that wasn't good. Now, it's hopefully really fixed.

How have you managed to install CentOS 7? It throws me error somehow, I do not know if I need something else.