Hello, before you shoot me down and suggest noddy answers to what is clearly a complex problem. Please read this post fully.
I have a virtualmin host with a virtual server. The virtual server is already running a variety of applications perfectly well. There are no Apache or PHP issues. Wordpress runs perfectly as does Roundcube webmail.
The install target is a sub folder of the webroot with a redirect configured to send all domian.com/crm to the correct sub directory of the web root. The installer web page comes up. And all seems ok apart from the install fails with the following message.
I spent half a day trying to get to the bottom of it. Started again and tried the command line install. Failed! Tried creating the DB first just in case it was some kind of DB create problem. Fails!
Can you tell me what logs or give logs for your attempt via the installer route? Am familiar with webmin for suite install but without any concrete logs it could be a myriad of things? And I’m most familiar with the gui install
Nothing shows up in the virtual server php error logs or the apache logs. Also now I am running 8.1.27 for this virtual server the server meets all compatibility.
The thing that jumps out at me is there are indeed 2 static declarations in that php file!
I’ve seen that sfh error recently, I’m not sure is it was here in the forums, or on GitHub. I can’t go search for it right now, but you can try and hopefully there will be some help there.
I also suggest clearing the symfony cache.
I fear that getting everything installed on an unsupported PHP 8.3, and then changing it, might not be enough to get a working installation. We don’t know which parts of the installer had problems with the unsupported PHP…
Yes we deleted the entire sub directory containing the installation. Dropped all the tables from the DB and started from scratch after dropping the virtual server down to php 8.1.27.
The install then worked via the ui (didn’t try via command line)
But there are still php issues which seem to be stopping us using it! Need to solve as need this inproduction.
I’m running both ubuntu dedicated server v8,5 and also Virtualmin for the comparison tests. I had similar issue with the CLI version of PHP not being the same version as Suitecrm runs during install. You can check what SuiteCRM is seeing by going to the Admin page and running diagnostics for the phpinfo and check the PHP version. It might not be what you saw in CLI. That is an easy fix if not PHP 8.2 or 8.1,
My work reveals the ubuntu clean server acts differently than the same ubuntu in Virtualmin.
Vanilla ubuntu server will install files and directories as crm:crm [whatever your user is] for ownership state. Virtualmin will do the same with some root ownerships tossed in. Virtualmin requires the correct owner to operate but it will be running under apache (my previous Centos7 test server) or www-data in the case of current ubuntu servers.
You will find the ownerships when you run the FIND commands post-install and I recommend piping the output to log files to compare what changes as you run SuiteCRM. They will change. I found I needed different attention to the Crontab permissions, directory and file ownerships compared to the version not running on Virtualmin. I believe this is because SuiteCRM is not self-aware of its ownership status or the server it is running on (it should be). The fact it didn’t flag an unapproved PHP version is symptomatic of the issues you will be seeing. IMO you cannot possibly run production v8.5 on Virtualmin today unless you are doing daily backups and can afford to lose a day’s transactions. Also, if you are running v8.51 think twice about going to the next version. It will be another mess as we’ve experienced from each version since v8 beta. Upgrades tend to wipe fixes you have made so just stick with v8.51 it if you get it working on Virtualmin.
My understanding from the server guys is that virtualmin will want the “crm” owner to own files and directories. Virtualmin will balk because it will be running as apache or www-data.
if you wish to share findings I think the Virtualmin fix is the way to go because of the features for casual users (like me). The bottom line is same installation on Linode servers acts differently for a virtualmin server. They don’t work equally and this adds confusion to an already troubled v8x.
Not sure. By default, Virtualmin runs PHP applications with PHP-FPM mode, the best mode of running PHP for web applications. The user account’s username and group, is the one Suite is installed on. So when you install Suite under the account mycompany, then the default directory is /home/mycompany/public_html/ or optionally a subdirectory under /home/mycompany/homes/username/. You probably should install under a subdomain (in Virtualmin, a “virtual server” for your subdomain) to keep the CRM application at crm.myorganization.tld and its database, separate from your organization website at www.myorganization.tld and its database.
We have been using Virtualmin for well over a decade. Modern versions use PHP-FPM and the process owner and group are the same as the virtual server. mydomain:mydomain
Running find across the installation folder does not show up any inconsistencies in owner and group permissions. Although my process is to install via the gui and then before logging in run the fix permissions commands.
It is always installed in a subdirectory under the /public_html webroot.
Also redirection complexity is also annoying. The only way I have found to make it work is to setup a web redirection in the virtual server for mydomain using an explicit folder like /home/mydomain/public_html/suitecrm/public/
Seems to work but it would be great to have all of that inside the installation root.
We are just coming back to this after a good few years away.