Brand new Virtualmin installation on a brand new 18.04 OS install.
I created the virtual server and installed the WP script.
When I access the initial WP install page, I get the initial dialog:
http://www.domain.com/wp-admin/install.php?step=1 But when I fill it out and proceed, it hangs. This happens on both of the only two virtual domains I have installed.
Nothing pops up when I tail the error logs simultaneously. I’m stuck. Something’s not right.
It sounds like a permissions problem.
Either your folders and files don’t have the proper write permissions or the database itself doesn’t and the installer can’t write to it to finish the setup.
That may be the case, however note the O.P is saying this is a brand new virtualmin system. If it was setup using the automated virtualmin installer, then how is this possible?
The questions that need clarification,
Simple: He used a different user and/or credentials to set up WordPress that doesn’t have the same permissions as the admin that set up the virtualserver.
The installer script for wordpress creates its own wordpress user in the process…it doesnt necessarily use the virtual server owner user. It depends also on whether a new database was created or the existing one used. However on a default install, nothing should go wrong .
It’s probably not permissions and it’s definitely not a different user (but it’s possible PHP execution as the domain user isn’t working).
Try different PHP execution modes. FPM is probably the best choice for new deployments. But, if you’re already using FPM, try switching to FCGID+suexec just to see if we can generate some kind of useful error or change in behavior.
Good deal then. That’s what I did wrong when I did it. I installed Virtualmin as the same user I set up my server with, then tried to use a site admin to install the Wordpress. It turned out I didn’t have the permissions to write to the database and that’s why it failed.
I don’t think I understand what you mean. You can only install Virtualmin as the root user (or using sudo). It is literally impossible to do anything else.
Again, I don’t think I understand. If you used the Virtualmin Install Scripts function, you can’t get the wrong permissions. It installs as the user that owns the domain an configures PHP to run as that user and using a database user that is also connected to that user.
public_html for both sites are populated with all of the required WP files including the newly created wp-config.php upon script installation.
I can login to mysql locally from the command line for each server.
I have added 3306 as a port forward to pfSense to the server.
I have opened 3306 in FirewallD and applied settings.
If I try to check the port from a remote location using a port checker, it reports that it’s closed…but that shouldn’t have any bearing on internal connection, especially since I can connect to the database directly on the server cli.
I installed PHPMyAdmin on one of the servers to confirm that I could connect to the database and I couldn’t until I changed MYSQL bind address to 0.0.0.0.
Even opening up permissions beyond what’s safe didn’t solve the problem. I manually configured wp-config and manually installed the files for wordpress and it worked.
The install script routine for Wordpress continues to fail.
The default script was used from the Virtualmin license from my license list in my account to install Virtualmin on a fresh install of Ubuntu 18.
Fresh except for one thing.
I had enabled UFW and allowed OpenSSH, but that’s it. Nothing else installed with the OS. Just a blank slate. I also didn’t customize any settings and let Virtualmin just go with default on everything.
At one point, I noticed that the disk quota was exceeded for one of the virtual server accounts, but I adjusted that and it hasn’t shown any additional errors in that respect.
Did you try what I suggested above?
That will break things, even if they’re working. So, that’s not a troubleshooting step. It’s just superstition.
Firewall is irrelevant, too, as long as your database is running on the same server. Don’t waste time on it.
We need to see the errors. Are you sure you’re looking in the right logs? Every domain gets its own logs when configured with Virtualmin, so the “main” error log is not relevant. Logs are stored in /var/log/virtualmin and are named in a way that should be intuitive. If running under FPM, it may have its own logs. But, as I suggested above, you were going to be trying to run it under suexec+FCGId and report back, so you can check the error log when you do that.
One of the most frustrating experiences that I have in this world is when it’s suggested to do something without instructions on how to do it. Under Server Configuration --> Website Options there are a few options at the top, and the one that was selected by default is FCGId, (run as website owner).
I don’t know what suexec+FCGId is nor where to find it, nor why, after installing a fresh install, I’m having to troubleshoot and tweak configurations. Tweaking configurations here inevitably leads to having to tweak something else there…and then down the road I discover that everything is jacked up.
That’s the impetus for this install in the first place. I’ve had a Virtualmin server running for a few years now and I fear that I’ve been limping along with all sorts of misconfigurations so much so that recently my Wordpress sites just quit working altogether and I’ve been unable to restore it. So, I’ve fired up this new server to start fresh, and here we are…with problems…and to compound the problem, this happened today when attempting to create a new virtual server:
I understand how to kill a process, but why?
Apologies, I’m working from memory. If you’re using FCGId execution mode, you’re using suexec. They always go together in Virtualmin.
Try switching to FPM. It may give different results which may be useful information.
But, also look for the domain error log. There have to be clues somewhere about why it’s failing.
I don’t know why, either. We support a huge array of configurations. My most recent tests haven’t shown any problems, and we use and test Virtualmin daily (as do 150k+ others). But, it’s a frightfully complex system. Sometimes things are different on the OS images people get from their hosts in ways that break things. Sometimes upstream pushes package updates that break things. We’re four people all working part-time, mostly volunteering our time. We do the best we can.
I have no idea. I’ve literally never seen that error.
So this is strange. After that error, I rebooted the system to try again, but lo and behold, the virtual server I was trying to create was now there.
The problem I have now is that in my experience, when errors occur during a process, the process didn’t actually complete correctly.
I mean an error that is a lie is also bad. But, I don’t know what would trigger this error, so I’m not sure where to start on making sure we aren’t giving misleading errors. 
Is this running on a networked filesystem, by chance? Locking using traditional flock doesn’t work on a network-mounted filesystem (at least, not NFS, and probably others). It’s possible to install an extra Perl module to resolve that in some cases, but I kinda thought Jamie already had an NFS safe flock in Webmin core, but maybe this was from an outside process that doesn’t. I’m just guessing wildly and rambling, so there’s probably no solution here. But, I’d rather understand the root cause of the error than not.
Not sure how to answer the question.
For simplicity…it’s a Supermicro, single processor server at 1.6GHz with 4G ram and 3 250GB SATA Drives.
I used the 18.04 LTS image to boot and install from a USB Key. Initially set to DHCP, after firing it up for the first time, I connected via SSH, enabled UFW, allowed OpenSSH, apt update, apt upgrade, then switched to root user and ran the wget script on my license at Virtualmin.
Once I was able to get into Virtualmin, I changed the network setting to static and created my first Virtual server.
No other configuration changes were made prior to this.
I added my google MX information to my DNS records for the virtual server, repeated this process for another virtual server, installed Wordpress script on both, opened 3306 in FirewallD (router was already set), pointed pfSense NAT services to the new box’s IP, and that’s about it.
I haven’t done any other tinkering with anything.
Perhaps I have a hardware issue as well…
Unnecessary, if everything is running locally.
True, but I am running HomeAssistant in Docker on another smaller system running 18.04 that needs to be able to access MySQL.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.