You are here
BLAdmin - Wed, 2026/01/28 - 05:54
Hello All,
I'm a new user here and was looking for a maintained version of SuiteCRM. Looking to demo it to my bosses so we can get off the old paper systems.
I'm new to TurnKey but had been using Bitnami until late for similar maintained apps.
Forum:
Tags:
Hi there.
Unfortunately all of our appliances are getting a bit "long in the tooth" as they say so I can't help you with an up to date version (latest SuiteCRM release is v8.9 - our appliance still only ha v8.4). Although perhaps our current one is good enough for your current purposes? Alternatively updating SuiteCRM within our appliance shouldn't be too hard.
FYI our appliances are based on Debian and where possible we use the default software provided by Debian - albeit with some config hardening and some custom software. So unlike Bitnami, the only custom TurnKey commands/software provide additional value or ease of use. So for general usage very little TurnKey specific knowledge is required. Changes that you may wish to make will (generally) be consistent with "vanilla" Debian (Ubuntu docs are usually "near enough" too - as that is also based on Debian).
The only specific knowledge you should need to get SuiteCRM up and running are noted on the TurnKey SuiteCRM appliance page. Then you can use the SuiteCRM upgrade docs. Everything should continue to "just work" - except with a newer SuiteCRM version. Note that some of the core "built-in" software versions (e.g. PHP) will be a bit old, but Debian provide security updates for another few years and I double checked the SuiteCRM requirements and our current server fulfills them.
Please let me know if you have any problems or further questions and I'll get back to you ASAP (albeit a little slow here sometimes). Ideally open a new thread on the forums - although I'll see a reply here too if need be.
Alternatively, if you start a free trial of our "TurnKey Hub" service you can access our "paid" support there (available when subscribed to a paid plan - even during the free trial period).
Regardless I do hope to push updated appliances ASAP - including a rebuilt and updated SuiteCRM appliance. However as a community driven project, we don't have the resources that Bitnami do so I don't have an ETA.
BLAdmin's response
BLAdmin replied via email and it should have been auto posted as a comment/response. But for some reason it didn't. So I'm manually copy pasting the content here. I figured that while I was at it I might as well move it to a new support thread.
I'm no SuiteCRM expert.
I'm no SuiteCRM expert - my knowledge tends to be generic and broad rather that application specific. Although I'm intimately familiar with TurnKey and having said that disclaimer in my experience many/most apps tend to broadly work in similar ways.
With that context out of the way, I'll respond to your points.
They may well be moving to an angular/js heavy build, but angular is a front end library, so it doesn't exclude use of PHP server side. I can't speak to the specifics of SuiteCRM, but I suspect that they are offloading lots of the functionality to the (angular/js) front end and probably more cleanly separating the front and back ends. I strongly suspect that the model they are shifting to is using their existing restful API to communicate between the js frontend (that runs in the user's browser) and the PHP backend.
Re contributions - they're always welcome! :) Whatever you are willing and able to contribute is always welcome. FWIW the SuiteCRM build code is hosted on GitHub - the shared code (e.g. general Apache, PHP and MariaDB config and setup) is within our "common" repository. Suggestions/feature requests/bug reports etc can go on on consolidated "issue tracker" (also on GitHub).
Re the domain, if you are using it in-house there are a few workarounds. You could give the server a static IP and then either add a domain to your local PC hosts file (pointing to the server IP) or just use the IP as the "domain". To update the domain, rerunning the firstboot script should do the job:
Re the issues you had with the log in breakage, my suspicion is the mod_evasive Apache module (essentially a WAF). To test my theory try just disabling it:
Re the archive servers, we use the URL recommended by Debian - i.e. 'deb'debian.org' which should auto redirect to the closest CDN. So the issue was likely a temporary issue with the CDN that it redirected to. I'm in Australia and occasionally (although very rarely) the CDN gets out of sync and can cause issues - as you note using a specific mirror URL usually resolves that. The other possibility is that if you have some sort of proxy between you and the internet perhaps the traffic was being mangled a bit? Regardless, glad to hear that you worked that out.
Re the subdomain - it sounds like I may have misunderstood your earlier mention of that? Or perhaps I'm misunderstanding it now?! :)
Anyway as I noted above, updating the "domain" for an existing SuiteCRM instance should be pretty straight forward. If the above doesn't "just work" please let me know and we can try to work out why. If the lack of a static IP is the core problem - and setting a static IP isn't an option - then the only thing I can think of is setting up a dynamic DNS client. Exactly how you would do that (or if it's even possible) will depend on your DNS provider. I forget the name of it but there is a "swiss army knife" type DDNS client in the Debian apt repos and IIRC it's fairly well documented and has instructions for the most common DNS providers.
I hope that's of some use...
Thanks for the Reply
I'm running short on time, but have spent more hours than I'd like to admit to get this 'working.'
Again, I think if I were rolling it out to a 'Real' production server with 'real' domain, then I think there wouldn't be any issues.
Its currently my understanding that OSCP stapling might continue to be an issue especially while in bare IP testing environments...also don't want to lower the the security as 70% attacks are Web-Based/Browser-Attacks.
The best almost working image I have been able to create is to:
Download the Turnkey iso.(suitecrm 18 build)
Proceed with setup carefully noting SQL is not root nor admin but "adminer."
Deltree the /var/www/suitecrm bit.
Reinstall a fresh downloaded SuiteCrm8.9.2 (from SuiteCrm Website)
Can get a few pages to load using a certbot workaround. Then eventually approximately any six page clicks and causes some kind of crash/panic in the PHP backend and logs the user out.
Theres also a nagging error about records not being stored but believe its a false positive(some fixes have been proposed by those in the SuiteCRM community but mostly not accepted as true solutions. (Their issue not Turnkey))
Anything anyone can offer would be of use.
Thanks to all and Thanks Jeremy for going so thoroughly through my questions and addressing them all.
BLAdmin
BeatTheGeek
I had a quick look last week and I have some info...
I got it to work and intended to post back sooner. I took some notes but wanted to do a test on a clean install to make sure there wasn't anything missing from my notes. But I haven't yet had time to circle back to that yet so rather than leave this hanging any longer here are my notes:
Also, the "domain" set in the firstboot script (/usr/lib/inithooks/bin/suitecrm.py) should actually be a URL - i.e. needs to include the schema too. E.g. 'https://wwww.example.com' - not just 'www.example.com'. Rerunning the firstboot script with a URL should work, but I manually updated it in /var/www/suitecrm/public/legacy/config.php. Also, at some point (I think during the upgrade process documented above) SuiteCRM tries to contact itself and it uses the URL that it is configured to be served on. It should work as-is if you are using a VM's static IP as the "doman" (URL) or are using a "proper" resolvable domain (URL). But if you are using a "dummy" domain set in your client hosts file (as I was during testing - I used 'www.example.com') then it will fail by default. A workaround is to add the dummy domain to the server's /etc/hosts file too. I.e. I added 'www.example.com' to the first line. So it went from:
to:
Finally, while I was poking around I also discovered that the cron job we ship with SuiteCRM is buggy - see the bug report I opened on our issue tracker.
Another note... after re-reading the post I'm responding to, I'm not sure that my brief testing was enough to recreate the primary issue you hit (i.e. the panic/crash). FWIW here's what I did:
I think I've worked out the 2 issues...
I had a look at the system journal and as I suspected the cause of the "permission denied" error was Apache - specifically the "mod evasive" (anti-DoS) module blocking me. So I loosened the config for that and that stopped the "permission denied" error from reoccurring. I bumped the 'DOSPageCount' to 5 (default is 2) - with all other settings unchanged, that allows 5 page loads within a second (instead of 2) before it assumes you are malicious. That will still minimize the harm that someone malicious can do but reduces the chance of "false positives" significantly. Here's a line to do that - and then Apache needs to be restarted to apply the change (i.e. the second line):
I'm also pretty sure that I've worked out the "Error occurred while retrieving records" problem. It's a bit of a strange one that I've never hit before. SuiteCRM tries to write to /var/lib/php/sessions but it's owned by 'root' so it can't write there. It seems to be some sort of session cache file but TBH I'm not clear why SuiteCRM tries to write there rather than somewhere within it's own file tree (which is already owned by the webserver), but changing the ownership of that dir to the webserver user seems to solve the issue.
Add new comment