Background on this is I tried to do a distribution upgrade from Ubuntu 16.04 LTS to Ubuntu 18.04.1 LTS on Monday. I spent the weekend before the upgrade backing up all my virtual servers, databases and configuration files/settings. The sudo do-release-upgrade failed. I was asked about keeping the old Postfix settings or using the new 18.04 ones and I selected to compare the versions. The differences got displayed in what I think was vi and I didn't know the exit command so I guessed and the install script got aborted. The machine immediately became unusable. Their USB Image installers didn't work so I had to wipe and put a new minimal 16.04 on then sudo do-release-upgrade before doing anything else.
BTW I didn't realize that restoring Webmin configs was a bad idea after installing a new OS and had to erase and reinstall the OS then Webmin. Those backups must only be good for restoring to an identical OS.
Yesterday I finished putting databases back in as well as meticulously putting settings back into Postfix. Around 5-6pm yesterday I ran the restore all for my Virtualmin Servers. So the spinning gif for the [Show What Will Be Restored] button has been going for 18 hours now. Could that be normal? The backups were about 182GB total for 14 Virtual Servers. I noticed that the disk space used went up dramatically after starting the restore procedure.
Will this eventually finish or fail? Help me Obi-Wan Kenobi, you're my only hope!
Comments
Submitted by JamieCameron on Sat, 01/12/2019 - 19:05 Comment #1
What I'd recommend is instead restoring using the command-line tool
virtualmin restore-domain. This will skip the confirmation step, and will avoid any potential browser timeouts.I didn't know about that command! COOL! I see this for guidance https://www.virtualmin.com/node/57003 but wonder if you made a man page for it?
virtualmin restore-domain --source /home/somebackupfileforadomain.tar.gz --all-domains --all-features --except-feature dns --only-featuresseems to have flags I don't want in my situation, and I wonder if I can point it at the folder with all domain backups instead of specifying one single domain.So what do I do about the current state? Does that command line just blow over the same disk space that any temporary files have been fluffed into? Will all be normal again after the command line method finishes?
Found the man page! (I think)
https://www.virtualmin.com/documentation/developer/cli/restore_domain
So I didn't realize it was a bad idea to restore all my MySQL databases before trying to bring in the Virtual Servers with a restore. The command line restore is obviously superior. It failed on my first go with error messages of
.. WARNING - The following features were enabled for one or moredomains in the backup, but do not exist on this system. Some
functions of the restored domains may not work : Git repositories
and
.. the following warnings were detected :
A MySQL database named myfavoritedatabase already exists
Restore failed!
I then realized I should have only restored the databases that Virtualmin didn't create.
I ran the second attempt before going to bed. This morning, I saw one of my top level servers was complete, but I snagged on another related message to MySQL. The error message that came in the shell window while I slept was
.. the following warnings were detected :
A MySQL user named myfavoriteusernameformyfavoritedatabase already exists - try selecting a different administration username
Re-starting DNS server ..
.. done
Applying web server configuration ..
.. done
Re-loading Webmin ..
.. done
Restore failed!
So I realized my ignorance. Obviously the databases that Virtualmin made had users too; obviously now.
Restore is working pretty good aside from my newbie-ish-ness, so I'll probably be closing this issue by tonight.
Submitted by andreychek on Sun, 01/13/2019 - 12:11 Comment #5
Glad to hear things are coming along!
Yeah, Virtualmin will restore all that databases that were previously associated with the domain, along with any database users, as you're seeing.
Feel free to let us know if you have any questions though!
I'm seeing a new problem that I don't know what to make of. Since I'm running Ubuntu 18.04 now with the PHP 7.2, I'm seeing restore messages like this:
Enabling PHP modules for restored scripts ..
.. no PHP modules needed to be installed
WARNING - The following scripts used PHP versions that are not available on this system :
somesites.com - phpPgAdmin - Version 7.0
somesites.com - phpMyAdmin - Version 7.0
Do I uninstall the PHP-Admin's then rerun the Virtualmin install scripts? Do I edit some config file and reboot?
I saw those messages for two domains so far. One see has the MySQL one working fine but not the PG; its throwing this browser error:
Your PHP installation does not support PostgreSQL. You need to recompile PHP using the --with-pgsql configure option.I tried tweaking the PHP .ini files to support the features by removing some leading semicolon's, then reloading Apache, but no joy.
Submitted by JamieCameron on Mon, 01/14/2019 - 17:31 Comment #7
You can ignore the first message, since PHP 7.2 and 7.0 are likely fully compatible.
As for the second, try installing the PostgreSQL module for PHP .. there should be a package in APT for it.
I was installing packages last night and this morning. You were right, installing php-
extension's solved the problem. HOWEVER, I may have run into something you need to update in the near future. The install script for phpPgAdmin won't work for me with Ubuntu 18.04 and PostgreSQL version 10.6, phpPgAdmin loads right but throws an error message about PostgreSQL version being incompatible. Theirs a newer version of phpPgAdmin, so maybe it's something you were going to do anyway.Submitted by JamieCameron on Mon, 01/14/2019 - 21:13 Comment #9
Interesting .. what's the error message exactly?
Uploading photos, ... maybe?
Submitted by JamieCameron on Tue, 01/15/2019 - 23:22 Comment #12
Which version of phpPgAdmin are you running there? My guess is that you need to upgrade it, which can be done from within Virtualmin.
It's phpPgAdmin 5.1, the latest version allowed by the Virtualmin Install Scripts. On the phpPgAdmin page, they're showing a stable 5.6 release.
Submitted by JamieCameron on Wed, 01/16/2019 - 21:23 Comment #14
Virtualmin supports up to version 5.6 though.
Make sure you are running the latest available scripts by going to System Settings -> Script Installers -> Installer Updates and clicking "Save"
Awww, snap! That did the trick. I assumed that a fresh Virtualmin on a fresh OS didn't need any updating yet.
Although, there may be a new problem...
After running the upgrade installers on one domain with both php__Admin's, I got the following error messages and I think they're related to something I saw about
mcryptbeing deprecated in PHP 7.2:Upgrading phpMyAdmin to version 4.8.4 ..
PHP module mcrypt is recommended ..
Enabling module in PHP configuration ..
.. done
Installing package php72-mcrypt ..
Installing package(s) with command apt-get -y -f install php72-mcrypt ..
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package php72-mcrypt
.. install failed!
Installing package php-mcrypt ..
Installing package(s) with command apt-get -y -f install php-mcrypt ..
Reading package lists...
Building dependency tree...
Reading state information...
Package php-mcrypt is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'php-mcrypt' has no installation candidate
.. install failed!
Installing package php7.2-mcrypt ..
Installing package(s) with command apt-get -y -f install php7.2-mcrypt ..
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package php7.2-mcrypt
E: Couldn't find any package by glob 'php7.2-mcrypt'
E: Couldn't find any package by regex 'php7.2-mcrypt'
.. install failed!
.. failed to install!
Configuring webserver PHP settings ..
.. already done.
Downloading https://files.phpmyadmin.net/phpMyAdmin/4.8.4/phpMyAdmin-4.8.4-english.zip (6.10 MB) ..
Received 15.65 kB (0 %)
Received 625.65 kB (10 %)
Received 1.22 MB (20 %)
Received 1.83 MB (30 %)
Received 2.44 MB (40 %)
Received 3.05 MB (50 %)
Received 3.66 MB (60 %)
Received 4.27 MB (70 %)
Received 4.88 MB (80 %)
Received 5.49 MB (90 %)
Received 6.10 MB (100 %)
.. download complete.
phpMyAdmin installation complete. It can be accessed at http://somehost.com/phpmyadmin/.
.. done
Upgrading phpPgAdmin to version 5.6 ..
Configuring webserver PHP settings ..
.. already done.
Failed to upgrade scripts : Download of http://downloads.sourceforge.net/phppgadmin/phpPgAdmin-5.6.tar.gz failed : HTTP/1.1 404 Not Found
Submitted by andreychek on Wed, 01/16/2019 - 22:56 Comment #16
PHP's mcrypt module was removed as of PHP 7.2... however, it looks like the issue in the above is that there's a 404 error when trying to access the 5.6 version of phpPgAdmin.
Jamie, it looks like the download links may be at a different provider now, you can see the links here:
http://phppgadmin.sourceforge.net/doku.php?id=download
Submitted by JamieCameron on Thu, 01/17/2019 - 21:47 Comment #17
Try updating the installer again now, and see if that fixes the issue with the download URL.
BINGO
Upgrading phpPgAdmin to version 5.6.0 ..
Configuring webserver PHP settings ..
.. already done.
Downloading https://github.com/phppgadmin/phppgadmin/archive/REL_5-6-0.tar.gz ..
Downloading https://codeload.github.com/phppgadmin/phppgadmin/tar.gz/REL_5-6-0 ..
.. download complete.
phpPgAdmin installation complete. It can be accessed at http://somehost.com/phppgadmin/.
.. done
and the full Monty when launched.
Submitted by JamieCameron on Sun, 01/20/2019 - 15:34 Comment #19
Great! Sorry, there was a delay in our automation that updates available script installer versions.