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: 
Closed (fixed)

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.

WNYmathGuy's picture
Submitted by WNYmathGuy on Fri, 12/20/2019 - 10:06 Pro Licensee

This is a bit of an emergency for me and probably related to the main issue so I don't think it needs a new issue. I just installed the upgraded PHP version of 7.4.1 but didn't run autoremove on my Virtualmin managed server. I did run autoremove on the other server and it wiped off the PHP 7.3.13 which was a surprise to me.

My Nextcloud instance is now out of service and I have a ticket about this on Github with them but it seems the solution to my problem is managing Virtualmin better than I am now. While using shell commands to try leaving maintenance mode I got this message This version of Nextcloud is not compatible with > PHP 7.3.<br/>You are currently running 7.4.1. which seems like a Virtualmin management issue.

I don't see a point and click way to force it to select the older version where things were working well. Here are some screenshots of what I'm seeing, https://drive.google.com/drive/folders/14vj0E4NXxl8O_Dgh20dCjwF39E0HYNgz...

Is there a quick and dirty fix of adding a line to that virtual servers apache directives?

WNYmathGuy's picture
Submitted by WNYmathGuy on Thu, 12/26/2019 - 11:23 Pro Licensee

Is it possible that because I was using Virtualmin to manage the DKIM part of eMail and that my BIND is dysfunctional that I'm not receiving mail for the domains? I mean it's nice to get a break from spam and so forth, but I just realized while trying to do a password reset, that I haven't received mail in my privately hosted eMail accounts since the fucking-up of my BIND server day. Maybe it's unrelated, but it's correlated.

Dec 26 12:04:45 srv1 postfix/smtpd[20873]: NOQUEUE: reject: RCPT from mail-wr1-f47.google.com[209.85.221.47]: 451 4.3.5 <myself@myvmindomain.com>: Recipient address rejected: Server configuration problem; from=<somebodyiknow@gmail.com> to=<myself@myvmindomain.com> proto=ESMTP helo=<mail-wr1-f47.google.com>
Dec 26 12:04:46 srv1 postfix/smtpd[20873]: disconnect from mail-wr1-f47.google.com[209.85.221.47] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7
Dec 26 12:06:04 srv1 postfix/smtpd[20873]: connect from o2.email.domainofsomebody.com[163.98.07.130]
Dec 26 12:06:04 srv1 postfix/smtpd[20873]: warning: connect to Milter service local:/var/run/milter-greylist/milter-greylist.sock: No such file or directory
Dec 26 12:06:04 srv1 postfix/smtpd[20873]: warning: connect to Milter service inet:localhost:8891: Connection refused
Dec 26 12:06:04 srv1 postfix/smtpd[20873]: Anonymous TLS connection established from o2.email.domainofsomebody.com[163.98.07.130]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Dec 26 12:06:05 srv1 postfix/smtpd[20873]: warning: connect to 127.0.0.1:10023: Connection refused
Dec 26 12:06:05 srv1 postfix/smtpd[20873]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Dec 26 12:06:06 srv1 postfix/smtpd[20873]: warning: connect to 127.0.0.1:10023: Connection refused
Dec 26 12:06:06 srv1 postfix/smtpd[20873]: warning: problem talking to server 127.0.0.1:10023: Connection refused
Dec 26 12:06:06 srv1 postfix/smtpd[20873]: NOQUEUE: reject: RCPT from o2.email.domainofsomebody.com[163.98.07.130]: 451 4.3.5 <myself@myvmindomain.com>: Recipient address rejected: Server configuration problem; from=<bounces+1381704-6878-myself=myvmindomain.com@mail.domainofsomebody.com> to=<myself@myvmindomain.com> proto=ESMTP helo=<o2.email.domainofsomebody.com>
Dec 26 12:06:06 srv1 postfix/smtpd[20873]: disconnect from o2.email.domainofsomebody.com[163.98.07.130] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6
Dec 26 12:06:22 srv1 postfix/smtpd[20873]: warning: connect to Milter service local:/var/run/milter-greylist/milter-greylist.sock: No such file or directory
Dec 26 12:06:22 srv1 postfix/smtpd[20873]: warning: connect to Milter service inet:localhost:8891: Connection refused
WNYmathGuy's picture
Submitted by WNYmathGuy on Sat, 03/28/2020 - 13:38 Pro Licensee

A quick note to self here. I also didn't notice that AWStats software got uninstalled way back when things went awry.

do you have a backup of the virt config and the websites before the issue? if so i would blow out the machine..reinstall from ground zero..do a base install of virt and then restore your backup.

WNYmathGuy's picture
Submitted by WNYmathGuy on Mon, 03/30/2020 - 19:58 Pro Licensee

@hescominsoon line one of my TL-DR original post:

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

I have thought about your solution, but I was hoping that if I instead launched a different server from zero, maybe I could migrate the content there. I don't have funds for another server yet so its a low priority. Generally, all sites are being served the way they should, and this post is sort of a post mortem log now.

WNYmathGuy's picture
Submitted by WNYmathGuy on Thu, 04/09/2020 - 12:35 Pro Licensee

Another quick note to self here...

xinetd may have also been uninstalled during the initial fiasco. I was going to see if a port was in use today and noticed that the Unused Modules section had Network Services and Network Services and Protocols there. I went to put them back in and got the configuration error message which led to the discovery that xinetd didn't exist on my system.

It makes me wish there was a way to find what the list of core programs are for Virtualmin to see what I am missing. Some unused modules are unused for good reasons. A hack admin like me can't tell with certainty which are deprecated and which are recommended. While looking through the unused I see it varies between error messages from missing programs and buttons to install the module. I want to guess all the error messages indicate recommended modules that I loused up from being a hack. I'm seeing FirewallD not being active, but I have a vague memory of that being the preinstalled firewall of choice for Virtualmin.

Ilia's picture
Submitted by Ilia on Fri, 04/10/2020 - 06:08

It makes me wish there was a way to find what the list of core programs are for Virtualmin to see what I am missing.

There you go - -stack package is what you need to look at.

WNYmathGuy's picture
Submitted by WNYmathGuy on Sat, 04/11/2020 - 14:24 Pro Licensee

There you go - -stack package is what you need to look at.

So I was missing libfcgi-dev, ntpdate, php7.2, php7.2-cgi, php7.2-fpm, php7.2-cli, although I do have the 7.3.16 & 7.4.4 versions.

Of the Recommends list, I was also missing irb, rdoc, firewalld (and its dependencies), [mysql-server and mysql-client because I switched over to MariaDB], clamav-daemon, clamav-testfiles, php5-mysql, jailkit, php7.2-mysql, php7.2-mbstring, unrar, p7zip, and etckeeper, but it seems their are no candidates for the irb & rdoc programs.

Of the Suggests list, only the libpg-perl was missing.

WNYmathGuy's picture
Submitted by WNYmathGuy on Fri, 04/17/2020 - 20:36 Pro Licensee

New note to self but about progress on older problems in this thread. I got BIND to work as it should again. The path I took to fixing it was so sideways that it's hard to know what I did right. Here's a play-by-play of what I remember or took notes on.

After putting on PHP 7.2 again, I wound up with new troubles on some of my virtual servers. I couldn't resolve those difficulties so I decided to just keep it simple and run one version of PHP, and I picked 7.4 (but tomorrow I'm going to be trying to put an older version on again according to this https://www.virtualmin.com/documentation/web/multiplephp#toc-installing-... because the Moodle site I run won't do admin things under 7.4, see https://github.com/wiris/moodle-filter_wiris/issues/63#issuecomment-6143...).

I did try to get the Virtualmin to play nice with multiple PHP's by doing System Settings -> Re-Check Config but that threw errors:

The status of your system is being checked to ensure that all enabled features are available, that the mail server is properly configured, and that quotas are active ..

    Your system has 31.4 GiB of memory, which is at or above the Virtualmin recommended minimum of 256 MiB.

    Virtualmin is configured to setup DNS zones, but this system is not setup to use itself as a DNS server. Either add 127.0.0.1 to the [list of DNS servers] (https://sd.fqdn.tld:10000/net/list_dns.cgi), or turn off the BIND feature on the [Features and Plugins] (https://sd.fqdn.tld:10000/virtual-server/edit_newfeatures.cgi) page.

.. your system is not ready for use by Virtualmin.

Because I was still in a bind with BIND, I selected the list of DNS servers option and added 127.0.0.1 to the list. That was never a persistent solution. It nagged at me and I was urged to fix BIND. So then I carefully removed all older versions of PHP.

In the "fog-of-war" fighting back errors and non-working sites, I was getting a new error from a docker thing that runs my Nextcloud Office software:

docker: Error response from daemon: driver failed programming external connectivity on endpoint clever_golick ([--snip--]):  (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 127.0.0.1 --dport 9980 -j DNAT --to-destination 172.17.0.2:9980 ! -i docker0: iptables: No chain/target/match by that name.
(exit status 1)).

So I assumed that it was a BIND loopback error that I didn't understand.

With only one PHP installed I took a new run at BIND by carefully uninstalling all its software and hiding all folders and files that remained related to BIND, and I also removed the Webmin/Virtualmin BIND modules. Then after a reboot, I began reinstalling BIND. Things went as before when trying to uncheck the subservers DNS option, so this time I tried making the zones for all my URL's. Obviously I didn't do any more than putting the URL and an email address in when making the zones. That allowed me to uncheck the subservers DNS options, then the same for the main Virtual Servers DNS options. I then cleared out the BIND entries (maybe stupidly), then just for good measure rebooted the system again. Now I started adding back the DNS options to my sites (top-down) as recommended earlier in this thread and the entries were automatically rebuilt as advertised.

The thing that isn't right at this time is the BIND as I remembered it had a few default entries for loopback or other words I don't entirely understand. like the 127.0.0.1 zone, and a couple of others? I only have zones that are my FQDN URLS, and the root zone that appeared magically when I clicked something in the BIND module's main page. Any way to get a copy of the default files that BIND has on a new Virtualmin server so that I can copy and paste the default zones back in? I'm behind a NAT router if that makes a difference.

I also removed the Virtualmin Virtual Server BIND module using the Webmin -> Webmin -> Webmin Config interface. I thought I could search for that module to reinstall it but I was WRONG. Is there a way to get that back on?

Also something that stands out in my eyes is, "No PHP-FPM packages were found on this system."

Here's my "System Settings -> Re-Check Config" now:

The status of your system is being checked to ensure that all enabled features are available, that the mail server is properly configured, and that quotas are active ..

    Your system has 31.4 GiB of memory, which is at or above the Virtualmin recommended minimum of 256 MiB.

    BIND DNS server is installed, and the system is configured to use it.

    Mail server Postfix is installed and configured.

    Postfix is configured to support per-domain outgoing IP addresses.

    Apache is installed.

    The following PHP versions are available : 7.4.4 (/usr/bin/php-cgi)

    No PHP-FPM packages were found on this system.

    Webalizer is installed.

    Apache is configured to host SSL websites.

    MariaDB 10.1.44 is installed and running.

    PostgreSQL is installed and running.

    ProFTPD is installed.

    Logrotate is installed.

    SpamAssassin and Procmail are installed and configured for use.

    ClamAV is installed and assumed to be running.

    Plugin AWstats reporting is installed OK.

    Plugin DAV Login is installed OK.

    Plugin DNS Domain Registration is installed OK.

    Plugin Git repositories is installed OK.

    Plugin Protected web directories is installed OK.

    Plugin SQLite Databases is installed OK.

    Using network interface enp2s0f0 for virtual IPs.

    IPv6 addresses are available, using interface enp2s0f0.

    Default IPv4 address for virtual servers is 192.168.1.196.

    Default IPv6 address for virtual servers is fe80::226:55ff:fe26:df20.

    Both user and group quotas are enabled for home and email directories.

    All commands needed to create and restore backups are installed.

    The selected package management and update systems are installed OK.

    Chroot jails are available on this system

.. your system is ready for use by Virtualmin.
Ilia's picture
Submitted by Ilia on Sat, 04/18/2020 - 13:30

I thought I could search for that module to reinstall it but I was WRONG. Is there a way to get that back on?

Yes, you can go to Webmin/Webmin Configuration/Webmin Modules page and install Standard module from as bind8.

Any way to get a copy of the default files that BIND has on a new Virtualmin server so that I can copy and paste the default zones back in?

Simply go to Edit Virtual Server page and toggle (disable save, and enable, save) DNS as a feature.

WNYmathGuy's picture
Submitted by WNYmathGuy on Sun, 04/19/2020 - 11:16 Pro Licensee

Yes, you can go to Webmin/Webmin Configuration/Webmin Modules page and install Standard module from as bind8.

That was the easy one. When I was deleting them there were two. A second one appeared in the list under the Delete tab way down in the Virtualmin section of the list.

Simply go to Edit Virtual Server page and toggle (disable save, and enable, save) DNS as a feature.

That part I can do now just fine. I'm wondering what BIND Zones were there before I ever spun up a Virtual Server. Shouldn't there be a zone for 127.0.0.1 and at least one more? Like right here at the 3:16 mark of an old video of Webmin bind setup
https://youtu.be/jmcNUNA_B88?t=196
I see it has, a Root zone, 0, 127, 255, and localhost all there right out of the box. When I put BIND9 back on there were no zones at all. I'm looking for a script or something that will fix that and tried sudo apt-get -y purge bind9 bind9utils then sudo apt-get install -y bind9 bind9utils a couple of days ago.

Also, somehow trying to run two versions of PHP was a failure again for me, but the interfaces were working nicely in Virtualmin. I was able to learn how things are supposed to work where you can choose the version you want for a server / sub-server. I saw how the radio-buttons in Website Options affected other choices and Services. My websites were all fakakta though. I also never got both versions of FPM to work. Somehow the Virtualmin interface won't recognize the php7.4-fpm no matter what I do to get it to be an option in the system. The php7.3-fpm worked fine. And it seems like the Moodle site was jacked-up because of their software, not the version of PHP.

WNYmathGuy's picture
Submitted by WNYmathGuy on Wed, 04/22/2020 - 18:10 Pro Licensee

I see now that I was going through the PHP "doggie-door" ass-backward and that is where my trouble may have begun. Trying to add an older version of PHP must be a whole different thing than merely upgrading and running multiple versions. I went through the minimum software requirements for all my services and ran sudo apt-get -y -f --reinstall install on their minimum package lists. Now all my websites are working again despite having multiple PHP versions on the system. Nextcloud hasn't been tested on php7.4-fpm, and I can say for sure it doesn't work on 7.4!! After going to a version 7.4 only to see if I could get the PHP-FPM cleared up I stopped getting access to write to the files on the server through the Nextcloud interfaces. Going back to only 7.3 only made nothing work except basic HTML pages. I have more to learn about that PHP-FPM thing...

Somehow the cascading delete of "unneeded packages" that happened when I removed old PHP versions caused trouble that was hard to discover. I think I'm made whole now except for the BIND server default zones. That part seems trivial right now.

Is their a page that I can learn about managing multiple versions of PHP in Virtualmin?

I have php, php-cgi, php-fpm, libapache2-mod-php, php7.3, php7.3-cgi, php7.3-fpm, libapache2-mod-php7.3, php7.4, php7.4-cgi, php7.4-fpm, libapache2-mod-php7.4, and libapache2-mod-fcgid all installed, and the fcgid is enabled in Apache, but the mods for 7.3 & 7.4 aren't. Here is what the System Settings -> Re-Check Configuration output is now:

Apache is installed.
The following PHP versions are available : 7.3.17 (/usr/bin/php-cgi7.3), 7.4.5 (/usr/bin/php-cgi)
The following PHP-FPM versions are available on this system : 7.3.17 (php7.3-fpm)
PHP versions have changed to 7.3, 7.4 since last check. Regenerating any missing php.ini files.

In the Website Options section it seems the CGI Wrapper and FCGId options never work, but instead just download any page instead of rendering it. I'll experiment more with that now that I think I have a stable system.

So a systemctl status php7.4-fpm.service would show it running if 7.4 was the only version, and System Settings -> Re-Check Configuration would say No PHP-FPM packages were found on this system.. When 7.3 got added back as a second version, systemctl status php7.3-fpm.service showed it not running, and System Settings -> Re-Check Configuration would say The following PHP-FPM versions are available on this system : 7.3.17 (php7.3-fpm) and if I tried System -> Bootup and Shutdown to Start Now and On Boot the php7.3-fpm, php7.3-fpm.service they would remain in a state of Unknown, and No, but 7.4 was Yes, and Yes. It reversed after removing 7.4 to run only 7.3 (plus the sudo apt-get -y -f --reinstall install commands on 7.3), and later adding back 7.4.

I saw something about having one FPM listen on port 9002 and the other listen on port 9003, but I'm hopeful that Virtualmin has a better way to make it happen so that individual servers pick from any installed version..

WNYmathGuy's picture
Submitted by WNYmathGuy on Mon, 05/18/2020 - 13:58 Pro Licensee

My BIND problems are over! Mystery solved!

On a spare machine I did a fresh Ubuntu 18.04, then installed the Community Edition Virtualmin. I found only one difference, and it was a radio button:

Test server BIND settings screenshot https://cloud.ruppssites.com/index.php/s/x289XCPWZDJR4ew PNG image of Virtualmin 's BIND Config interface

Production server BIND settings screenshot https://cloud.ruppssites.com/index.php/s/kqxPdnQjMPttw7M PNG image of Virtualmin 's BIND Config interface

=====================================================

After switching that radio button for Is named.conf under chroot directory? from No to Yes the 5 default entries appeared in the interface.

Production Server Before the change https://cloud.ruppssites.com/index.php/s/f5AQQc5ygLxyfJw

PNG of Virtualmin BIND Main Interface

Production Server After the change https://cloud.ruppssites.com/index.php/s/PeFKfNo9P7Wmxz7

PNG of Virtualmin BIND Main Interface

Ilia's picture
Submitted by Ilia on Tue, 05/19/2020 - 17:34

..and if you change back again, will it still work? :--)

WNYmathGuy's picture
Submitted by WNYmathGuy on Wed, 05/20/2020 - 12:25 Pro Licensee

YES! In order to do the "Before" screenshot, I had to "Photoshop" the "After" screenshot because no matter which way I toggled that radio button I couldn't see the interface display the way it was before things went back to normal. It was an eye-rolling moment. I now assume that things were really working correctly but visually I didn't think they were looking at the interface.

It's all better again. I almost feel like a Systems Admin now. I fixed something instead of formatting and reinstalling from scratch.

I could be biased about this opinion but I think my systems are working more efficiently now. I have very few things to worry about anymore because Virtualmin works so well.

I had a weird quirk right after I discovered the BIND solution where somehow the FPM for 7.4 was set to not run at boot time, though the FPM 7.3 was. That wasn't a persistent problem. I have that one thing left where if I reboot I have to manually add the 127.0.0.1 back into the Network section for Hostname and DNS Client. I'm of the understanding that without a static IP, this problem will need to be tended to after any reboot of the server. Not a big concern of mine.

congrats on fixing it..but sometimes part of being a system admin is knowing when to burn it down and rebuild from backups. It becomes a time management thing. if you can repair it faster than you can restore from backups then it's worth the investment. Even with all of the issues i have had with virt their backup system is pretty reliable. Once I get my new server racked that has full remote ipmi then I can leave a usb stick inside the case and when virt goes boom I can remote in, switch to boot from the usb stick, wipe the box, reinstall, restore from backups in less than one hour..:) At that point nuking the box goes much faster than hours upon hours of troubleshooting.

WNYmathGuy's picture
Submitted by WNYmathGuy on Wed, 05/20/2020 - 12:55 Pro Licensee

Thanks, @hescominsoon, its sage advice that I will take in the future, but in the words of "Bandit 1" in Blazing Saddles "Backups, we don't need no stinking backups!" [laughs maniacally during walk-away].

I said I almost feel like a, not I am one. It's a near $0.00 budget personal project I'm working on and I had no back-ups to restore from.

Ilia's picture
Submitted by Ilia on Wed, 05/20/2020 - 16:49

It was an eye-rolling moment. I now assume that things were really working correctly but visually I didn't think they were looking at the interface.

Yes, it happens sometimes on Debian systems. It's a cache issue. New release of Webmin 1.950 will include the theme 19.50, which will have a Clear Cache link in dropdown in right side slider, which will clear a lot of caches, including BIND.

For that issue, all you needed to do is to delete /etc/webmin/bind8/zone-names file.

since it's a debian issue i assume you will include this functionality in Ubuntu version as well?

Ilia's picture
Submitted by Ilia on Wed, 05/20/2020 - 18:02

Yes, it's global feature, not tied to the distro.