I royally screwed things up changing PHP versions, now BIND has no entries

FYI: no I don't have backups to restore from, so shoot me.

One of my sub-servers was running Nextcloud and it was pressuring me to be upgrading to PHP 7.3 but because I'm a hack admin, I just assumed I knew what I was doing. I knew I was in serious trouble this afternoon when I rebooted the server and BIND, ProFTPD, and SpamAssasin weren't running despite me not touching them.

I don't know if this time travel review of the latest changes will help anything, but this is what I think may be relevant to my failure.

I installed the 7.3 version from http://ppa.launchpad.net/ondrej/php/ubuntu and because of his documentation, I added http://ppa.launchpad.net/ondrej/apache2/ubuntu to my list of apt sources file. I went to that virtual sub-server and altered its default PHP version. Things were going well.

Not long after that, I saw that my phpMyAdmin on an internal server managed with Webmin (not Virtualmin), was complaining about me upgrading to the new version. That also went well without trouble. I have been connecting to that internal servers database via a pass-through type sub-server on my Virtualmin managed server and I noticed the PHP version was listed as 7.0, so I thought (mistakenly) that changing it in the sub-servers PHP version settings it would alter it. When it didn't I realized it was just delivering what was processed on the internal server. About 10pm last night, I did the same thing to upgrade that internal servers PHP version as I did to my externally facing server. It was still saying that I was running 7.0 so I looked in Apache's module manager with Webmin. I saw the new version was off, so I enabled it. While I was at it I thought it would be good to do the same on my externally facing server. It turned out to be a bad idea, but I didn't know that till about midnight last night when I tried to access my Friendica server using the normal web interface. It let me see the login page but then never loaded the site. I tried deactivating the module in Apache, and that did nothing so I went to bed.

Today I tried more things including clearing browser cache and so forth. I was plagued by a variety of issues with all my sites, like PHP pages downloading instead of rendering. While trying to "Google the error message" I was led to things that made my problems worse, like adding some mime types like application/x-httpd-php .php. I became convinced that running two versions of PHP was unnecessary, and decided to uninstall php7.2 from my outward-facing server. After uninstalling it with the .com:10000/software/ module (with settings to purge and remove unused dependencies) I thought I was all set.

Well Apache wouldn't start, and I had to manually remove a bunch of things that got thrown into *.conf files, like rows starting with

FCGIWrapper RemoveHandler .php AddType application/x-httpd-php .php AddHandler fcgid-script .php FcgidMaxRequestLen IPCCommTimeout

After Apache was running again, the sites were still acting wrong. I rebooted. I saw the aforementioned services not running. I became shocked to find they weren't just not running, they were uninstalled. Apparently the user-specific files were gone too, not just the software. As of right now, my PHP pages display as plaintext in the browser. BIND has no zones for all my virtual servers. I'm hoping there's a way to regenerate the BIND entries.

I don't know what else I fouled up but things were a bit wonky in Postfix too.

Status: 
Active

Comments

Howdy -- thanks for contacting us!

Well, if you had made any customizations to the BIND configs, those would be lost -- but you can certainly re-generate the default DNS entries.

How many domains do you have?

If it's just a handful, a simple way would be to go into Edit Virtual Server -> Enabled Features, and to disable the BIND DNS Domain feature, save, and then re-enable it.

Once you do that, I'd be curious what output you receive if you were to go into System Settings -> Re-Check Config.

Note though that the above would only be necessary if your domains are using your server as a nameserver -- if not, you wouldn't need to have BIND DNS zones for your domains.

WNYmathGuy's picture
Submitted by WNYmathGuy on Thu, 11/21/2019 - 17:42 Pro Licensee

I have 3 top-level virtual servers. I have 12 sub-servers unevenly distributed among them.

You are right that they work without the BIND entries. I have been doing things to straighten out the PHP mess I got myself into and have all sites working despite no BIND entries.

I tried it with my first top-level virtual server (rookie mistake) and it said
Failed to modify server : DNS cannot be disabled while sub-domain still have it enabled,
so obviously I have to turn it off from the bottom up then on from the top down.

Unchecking the DNS domain enabled? and saving outputs:
Are you sure you want to save the domain subd.fqdn.tld? The following features have been selected for deletion :
BIND DNS domain - All DNS records in the domain and any BIND options will be deleted.
[ Yes, Save Now ]

Then the following printed to the screen:

Removing records from DNS zone fqdn.tld ..
.. DNS zone does not exist!
Updating Webmin user ..
.. done

Saving server details ..
.. done

Re-loading Webmin ..
.. done

After looping through 3 sub-servers I tried it again on a top-level one and got the same error message. I guess .. DNS zone does not exist! meant, it wasn't going to let me uncheck the box. I thought (from untrustworthy memory) that top-level virtual servers had top-level zone files. I assumed creating new zones would let me complete the removal of the zones. I tried adding the one fqdn I was working on so far. I got an error for not giving a valid email address, then on the second try it claimed the zone already existed, but it doesn't show anywhere in the Webmin portion of the Virtualmin interface.

I'm stuck.

Also, I've been changing the Website Options to use FPM as of now. I don't recall if I ran anything that had to use Apache mod_php (run as Apache's user). For some reason, no site has that Apache choice showing for it, just the other 3; CGI, FCGId, & FPM. Prior to switching to FPM many of the virtual servers were missing some or all of their ~etc/php7._/ folders. Most of them had 7.0, 7.2, & 7.3 after forcing the website options to FPM, just the servers made in the last 10 months don't have the 7.0 folder. I believe I can safely delete the 7.0 & 7.2 folders because nothing I have done was relying on older versions, and only one server had me modifying it's php.ini file's default. (side note: as a dumbass, I was typically editing the main php.ini file in the past instead of the one specific to the domain.)

In spite of the warning that you received while unchecking that option, it should be disabling the BIND DNS feature.

When going back into Edit Virtual Server, is it correctly unchecked after that?

Note that if you really aren't using your Virtualmin server as a nameserver, the BIND DNS domain features should all be disabled.

You shouldn't need to manually add any zones, or setup any sort of FQDN though (that would likely make things a bit worse).

If you're finding that you're unable to disable that BIND DNS feature, let us know and we'll come up with a different way to disable that.

WNYmathGuy's picture
Submitted by WNYmathGuy on Fri, 11/22/2019 - 10:28 Pro Licensee

It is not unchecked after that. It remains persistently checked when going back into Edit Virtual Server.

As an experiment, I unchecked the BIND setting in the Account Plans section. That setting change was persistent. After that, I tried again to uncheck the setting in Edit Virtual Server and the results were the same as before. Should I look around in File Manager to see if the original files for BIND DNS are still around and just not being recognized?

I thought that the BIND DNS part was a really cool thing I got from going into Virtualmin management from only Webmin. I'm not sure why I shouldn't try to use it. I wouldn't have all the subdomains listed in the DNS section of google's domain service if I thought I didn't need to. I did mindfully have Virtualmin doing my DNSSEC though. I'm not sure how important that was.

Sure, we can always look into using your server as a nameserver after this -- the key at the moment is just to try and get things back to a sane working state, as that seems to be the trouble at the moment.

Just to verify -- do they all remain persistently checked?

Or is it just the one for the top-level Virtual Server?

If it's just the one domain causing the problem, there's a way we can force Virtualmin into disabling that.

WNYmathGuy's picture
Submitted by WNYmathGuy on Fri, 11/22/2019 - 15:09 Pro Licensee

All sub-servers remain checked. I never get to uncheck the top-level one because it fails the sub-server test.