Hi all, I’m attempting to install SuiteCRM 8 to try out all the cool new features but instead of the installer appearing in my browser I get “Forbidden You don’t have permission to access this resource”.
I am attempting to install SuiteCRM-8.0.3.zip on FreeBSD v13 with PHP 8.0.15, Apache 2.4.52 and MariaDb 10.5.13, and using the recommended vhost definition in the installation instructions.
phpinfo reports my server php configure command includes ‘–disable-cli’. However “php --version” reports “PHP 8.0.15 (cli) (built: Jan 22 2022 01:15:46)”, implying cli is present.
“common” appears to be a distribution-specific collection of commonly used modules, and available on at least on REL but not on FreeBSD. My installed modules are listed below. Can anyone say if I’m missing any which would result in the “Forbidden…” error connecting to SuiteCRM 8?
Thanks in advance,
Dale
% php -m
[PHP Modules]
bcmath
bz2
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
gettext
gmp
hash
iconv
imagick
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcre
PDO
pdo_mysql
posix
Reflection
session
SimpleXML
soap
SPL
standard
xml
xmlreader
xmlwriter
zip
zlib
[Zend Modules]
%
Yes, I set permissions using the recommended procedure.
Fwiw, I successfully installed the latest SuiteCRM v7 release without issue. I suspect there is some subtle changes in how v8 is served, or perhaps the default apache configuration on FreeBSD that is causing me grief.
After this the installer ran and completed successfully, but after logging in as the new admin user the dashboard reports “Internal Server Error”. The error in the Apache log is:
[Sat Feb 26 17:53:06.910641 2022] [php:warn] [pid 92980] [client 62.210.215.100:49213] PHP Warning: Attempt to read property "post_type" on null in /usr/local/www/wordpress/wp-includes/class-wp-query.php on line 4273
@clemente.raposo if this now looks like the same issue, I would very much appreciate your insight.
This is my public/.htaccess
dale@whizzer:/usr/local/www/suitecrm/public % cat ./.htaccess
# Use the front controller as index file. It serves as a fallback solution when
# every other rewrite/redirect fails (e.g. in an aliased environment without
# mod_rewrite). Additionally, this reduces the matching process for the
# start page (path "/") because otherwise Apache will apply the rewriting rules
# to each configured DirectoryIndex file (e.g. index.php, index.html, index.pl).
DirectoryIndex index.php
# By default, Apache does not evaluate symbolic links if you did not enable this
# feature in your server configuration. Uncomment the following line if you
# install assets as symlinks or if you experience problems related to symlinks
# when compiling LESS/Sass/CoffeScript assets.
# Options FollowSymlinks
# Disabling MultiViews prevents unwanted negotiation, e.g. "/index" should not resolve
# to the front controller "/index.php" but be rewritten to "/index.php/index".
<IfModule mod_negotiation.c>
Options -MultiViews
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^index.php.*$ - [L,NC]
# Determine the RewriteBase automatically and set it as environment variable.
# If you are using Apache aliases to do mass virtual hosting or installed the
# project in a subdirectory, the base path will be prepended to allow proper
# resolution of the index.php file and to redirect to the correct URI. It will
# work in environments without path prefix as well, providing a safe, one-size
# fits all solution. But as you do not need it in this case, you can comment
# the following 2 lines to eliminate the overhead.
RewriteCond %{REQUEST_URI}::$0 ^(/.+)/(.*)::\2$
RewriteRule .* - [E=BASE:%1]
# Sets the HTTP_AUTHORIZATION header removed by Apache
RewriteCond %{HTTP:Authorization} .+
RewriteRule ^ - [E=HTTP_AUTHORIZATION:%0]
# Redirect to URI without front controller to prevent duplicate content
# (with and without `/index.php`). Only do this redirect on the initial
# rewrite by Apache and not on subsequent cycles. Otherwise we would get an
# endless redirect loop (request -> rewrite to front controller ->
# redirect -> request -> ...).
# So in case you get a "too many redirects" error or you always get redirected
# to the start page because your Apache does not expose the REDIRECT_STATUS
# environment variable, you have 2 choices:
# - disable this feature by commenting the following 2 lines or
# - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
# following RewriteCond (best solution)
RewriteCond %{ENV:REDIRECT_STATUS} =""
RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]
# If the requested filename exists, simply serve it.
# We only want to let Apache serve files and not directories.
# Rewrite all other queries to the front controller.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ %{ENV:BASE}/index.php [L]
</IfModule>
<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When mod_rewrite is not available, we instruct a temporary redirect of
# the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 307 ^/$ /index.php/
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>
dale@whizzer:/usr/local/www/suitecrm/public %
@aaronh yes, you are correct, my apologies. I must have copied the wrong line in haste, as I am confident I saw the same error posted by TripitakaBC:
…/usr/local/www/suitecrm/public/legacy/.htaccess: RewriteBase: argument is not a valid URL, referer: …
However, now after dropping and recreating the database, I get a blank screen instead of the installer. It’s been a long day, I will start over again tomorrow back at the beginning with re-extracting the distribution. Thanks for your help.
Fresh start and the installer completed successfully again. At least that much is consistent. This time I added a trailing “/” to the URL in the installer, hoping I understood TripitakaBC’s solution but no luck and got “Server Error” again after logging in. Most menus seem to work except for Home and Admin, that give Server Error.
The error message in the Apache log was as I recalled, and this time will copy correctly:
[Sun Feb 27 00:43:06.528377 2022] [core:alert] [pid 49765] [client 174.0.43.39:42438] /usr/local/www/suitecrm/public/legacy/.htaccess: RewriteBase: argument is not a valid URL, referer: http://suitecrm.dalescott.net/
I compared the …/public/.htaccess posted earlier to the current …/public/.htaccess (after adding a trailing “/” to the URL given in the installer) and they are identical. Reviewing TripitakaBC’s .htaccess again, there seems to have been significant changes made to public/.htacces since that time (Nov 2021), and I’m not knowledgeable enough about Apache re-writing to understand more.
I’m running out of ideas and any suggestions would be appreciated. Is it possible there are more changes required to my apache vhost definition for Apache 2.4?
Make CERTAIN that your suitecrm installation can resolve to that FQDN. The error is suggesting that it cannot which points to a DNS issue, possibly as a result of being behind a reverse proxy.
Hi @TripitakaBC. You can try logging in if you want. Username “dale” and password “LZY9n3PS6Rqi” (it’s a throw-away password and there’s no data yet in SuiteCRM).
OK, I get the Internal Server Error there after logging in which means we are back to the redirect error I got.
I actually gave up on SuiteCRM as it was to complex for my needs and as a beginner trying to deal with low-info levels on the new v8 release, I moved to EspoCRM which I’m still on. I know way more than I did back then so I may move back to SuiteCRM in the future. I share that just to give some insight that I’m not 100% up to date on current SuiteCRM.
It looks like you are running FreeBSD so I wonder if you are building this in a TrueNAS jail? If so, I have some build scripts I can share because I must have rebuilt that jail 20 times trying to resolve the issue and the scripts build it in about 2 minutes.
If I recall, I may have ended up on PHP74 due to issues with PHP80. I see you are on PHP80 so may be worth a try.
@TripitakaBC I missed your first reply. Reponse to curl seems to indicate suitecrm.dalescot.net is resolving. Fwiw I’m using noip.com for DNS and have separate domain entries for a number of vhosts. The other vhosts all use SSL with Letsencrypt certs. I created and installed a Letsencrypt cert for suitecrm.dalescott.net with certbot, and all worked ok with SuiteCRM v7. I then disabled SSL (commenting relevent lines in httpd-vhosts.conf and httpd-vhosts-le-ssl.conf) while trying to install SuiteCRM v8. At first it seemed Chrome would sometimes access SuiteCRM using SSL, but I attributed it to my SSL/non-SSL experimenting and it stopped after I cleared the cache in Chrome.
Thanks @TripitakaBC for confirming as much. I’m running SuiteCRM on baremetal FreeBSD v13 with PHP 8 (not in a jail). I will try upgrading to PHP 8.1 when I get a chance.
Thanks also for reference to EspoCRM. SuiteCRM is more CRM than I also need, but it’s the Projects module I’m really interested in. My primary focus is helping hardware startups manage parts, bills of materials and supply chain, accelerate new product introduction and scale production. I’ve investigated other web-based open source project management software and they have either been too simple (e.g. Nextcloud Deck) or too complex (e.g. OpenProject, ]project-open[, projeQtOr). The Projects module in SuiteCRM looked like it might be just right.
Startups generally also need to migrate from email contacts and spreadsheet CRM to something more formal, and I could offer SuiteCRM as another arrow in my quiver so to speak.
Thanks for the PM, I’ll ping you there.
If anyone has any other suggestions, I’m all ears. TIA
Solved! I re-installed from scratch again, but this time I used the complete URL in the installer (http://suitecrm.dalescott.net) and “127.0.0.1” for host address instead of “localhost”. After logging in the first-time wizard ran successfully (which it hadn’t before, only “Server error”). I then re-enabled the SSL re-writing generated by Certbot and re-installed one more time using https://suitecrm.dalescott.net as the site URL and the installer ran correctly again.
To summarize, compared to the V8 installation instructions, I
replaced “Order Allow,Deny” with “Require all granted” in the Apache vhost definition for Apache 2.4
installed php80-tokenizer (note that dom is also required, although not included in the installation instructions)
also in the insaller, I used “127.0.0.1” for the Host Name instead of “localhost”
Everything isn’t perfect yet however. I uploaded a photo to my user profile but it’s not getting displayed. I’ll troubleshoot a bit more and open a new topic if needed.
Also had to add to the virtual hosts file Directory settings:
Options FollowSymLinks MultiViews
AllowOverride All
Allow from All
Require all granted
I also add the crm.mydomain.com to the /etc/hosts and resolved it to the IP of the server
I also updated all composer files before installing. I did this by using Composer and then doing a “php ./composer.phar update” and then “rm composer.phar” to clean up.
I edited the public/legacy/config.php and placed the following at the top:
putenv(‘TMPDIR=/path/to/user/tmp’);
After doing all of that, I was able to finally get this working. Took 5+ hours if farting around.
It’s been a long day, I will start over again tomorrow back at the beginning with re-extracting the distribution. Thanks for your help.
This time I added a trailing “/” to the URL in the installer, hoping I understood TripitakaBC’s solution but no luck and got “Server Error” again after logging in. Most menus seem to work except for Home and Admin, that give Server Error.
TIA