Univention SuiteCRM

Before I fully give up on SuiteCRM, hoping I can be saved here. I have installed the image and run latest upgrade via univention to looks like 4.3.3 (this is digitech). It shows deb9 php 7.0 v 33 whereas it can be updated to 49. There is a bug on running the upgrade package and it seems there is some cache stuck and an issue with perms somewhere.

The API V8 does not work as the .htaccess file does not seem to be doing its job. I have compared this to a working on a different server and its not the htaccess.

Notes…apt update within the shell does update php. Biggest thing is how to get the Oauth to work. It is the issue I have seen before from Api/access_token with 404. Can anyone confirm if they have had any issues or know how to fix the Api/V8 on univention?

Hi there,

Have you manually created the private and public keys?

If so can you dump the contents of the .htaccess file to us please. If it’s just the default one you should be safe to do so here.

Lastly, can you confirm the CRM version found on the about page?

Thanks!

Hi Mac-Rae,
Yes I created the keys and followed the directions (Note I have done this on a couple other instances [not Univention though] no problem).

The About Page says version Version 7.11.3. Upgrade wizard page shows following:

7.0.33-0+deb9u6. The recommended php version is 7.1.0 or above. Ini location shows: /etc/php/7.0/apache2/php.ini

.htaccess file is below:

    # ---------
   # BEGIN SUGARCRM RESTRICTIONS-----
    RedirectMatch 403 (?i).*\.log$
    RedirectMatch 403 (?i)/+not_imported_.*\.txt
    RedirectMatch 403 (?i)/+(soap|cache|xtemplate|data|examples|include|log4php|metadata|modules)/+.*\.(php|tpl)
    RedirectMatch 403 (?i)/+emailmandelivery\.php
    RedirectMatch 403 (?i)/+upload
    RedirectMatch 403 (?i)/+custom/+blowfish
    RedirectMatch 403 (?i)/+cache/+diagnostic
    RedirectMatch 403 (?i)/+files\.md5$
    # END SUGARCRM RESTRICTIONS
    <IfModule mod_rewrite.c>
    Options +SymLinksIfOwnerMatch
    RewriteEngine On
    RewriteBase /
    RewriteRule ^cache/jsLanguage/(.._..).js$ index.php?entryPoint=jslang&modulename=app_strings&lang=$1 [L,QSA]
    RewriteRule ^cache/jsLanguage/(\w*)/(.._..).js$ index.php?entryPoint=jslang&modulename=$1&lang=$2 [L,QSA]

    # --------- DEPRECATED --------
    RewriteRule ^api/(.*?)$ lib/API/public/index.php/$1 [L]
    RewriteRule ^api/(.*)$ - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    # -----------------------------

    RewriteRule ^Api/access_token$ Api/index.php/access_token [L]
    RewriteRule ^Api/V8/(.*?)$ Api/index.php/V8/$1 [L]
    RewriteRule ^Api/(.*)$ - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    </IfModule>
    <FilesMatch "\.(jpg|png|gif|js|css|ico)$">
    <IfModule mod_headers.c>
         Header set ETag ""
         Header set Cache-Control "max-age=2592000"
         Header set Expires "01 Jan 2112 00:00:00 GMT"
        </IfModule>
    </FilesMatch>
    <IfModule mod_expires.c>
        ExpiresByType text/css "access plus 1 month"
        ExpiresByType text/javascript "access plus 1 month"
        ExpiresByType application/x-javascript "access plus 1 month"
        ExpiresByType image/gif "access plus 1 month"
        ExpiresByType image/jpg "access plus 1 month"
        ExpiresByType image/png "access plus 1 month"
    </IfModule>
    <IfModule mod_rewrite.c>
         RewriteEngine On
         RewriteCond %{REQUEST_FILENAME} !-d
         RewriteCond %{REQUEST_URI} (.+)/$
         RewriteRule ^ %1 [R=301,L]
     </IfModule>

A few notes of things I have done and have noticed to help troubleshoot.

SSHing into the univention the suitecrm sits at /var/lib/suitecrm/suitecrm

Changing the htaccess rewrite base has no effect

I also noticed that in cache folder there is a subfolder cache with modules/Schedulers that are owned by root.

Doing a find I always get these process IDs that show up something to below (same but obviously different PID depending on machine)

find: ‘/proc/33803/task/33803/net’: Invalid argument
find: ‘/proc/33803/net’: Invalid argument

I have done the login via ucsadmin, installed, uninstalled, etc… Tried running upgrade using upgrade wizard but it gets stuck with patch 7.3 and upload folder wont work. Cleared DB and upload would persist after deleting field value in upgrade_wizard db. Now permissions issue with me tinkering but I will re-install.

With all this said, it appears that there is either a mount issue, nobody or something but I know its persisting because nothing I have done will resolve it. Let me know if you need anything else. Also, there is a persistent upgrade in the univention that is tied to digitec-suitecrm but the upgrade will not work. BTW there is only one user and memberserver so this should not be related to a license thing. Thanks in advance.

Any thoughts on this? I still keep getting an upgrade notification in univention and running via cli univention-upgrade it finds suitecrm update package then asks for administrator/pass. Then it fails. Logs say:

65235 actions.upgrade 21-03-03 11:06:38 [ WARNING]: NameError: name ‘app’ is not defined
65235 actions.upgrade 21-03-03 11:06:38 [ DEBUG]: /var/cache/univention-appcenter/appcenter.software-univention.de/4.3/digitec-suitecrm_20190329133335.preinst returned with 1

What a nightmare. It is 100% obviously a permissions somewhere, but also this is a security risk so they should probably take it down, no? Is the CVE from November fixed? Assuming no since unable to upgrade, its running 33 Deb which is up to 49 now I believe, composer cannot be run to upgrade, apache is running as root part of this thing but just for anyone else who is in same issue… Don’t waste your time. After fixing this who knows what next will break. So instead of actually getting work done, we spiral to nowhere to get nowhere. Sorry it must be said.

Ok, for anyone who needs to get past this point in univention. Not sure if this is the best approach or if it will cause other issues but I was able to get past nagging upgrade notification. Where an issue lies in within the univention cache folder. Problematic file appears to be
var/cache/univention-appcenter/appcenter.software-univention.de/4.3/digitec-suitecrm_20190329133335.preinst

This file as sys.exit causing the upgrade to fail so I commented this out and was able to upgrade by running
univention-app upgrade digitec-suitecrm

It still complains of a dependency for the package but did upgrade

Next, shell into:
univention-app shell digitec-suitecrm

For the oauth following the directions [Oauth2 setup]

Chmod 660 (pb/pv keys)

I installed nano to edit the .htaccess
apt-update
apt install nano

Change the Rewrite Base / to /suitecrm
RewriteBase /suitecrm

Then run
a2enmod rewrite
systemctl restart apache2

Now you have a working Api/access_token

Note there are issues with this method and most likely will get overwritten on Repair or upgrades but this will solve issue for now.