New Installation woes-- Need User Management to work

I just installed SuiteCRM on a cloud server. All appeared to go well. I had a previous instance running in my office and i exported most of all my records including users. In the last things todo was to reset passwords and email out to the users. There are only 10. I am finding that the Administrator cannot reset a password , nor create a new user. I can however delete a user. Also in the Password management None of the entries I make there are being saved. I have chmod -R 0777 the whole CRM directory and I have rebuilt roles and Quick repair and rebuild. There were no hiccups in the initial installation. I did export the users and import them from the old system, would that have affected this? Am I doomed to re-install without importing the users? HELP!

If you had simply migrated your database with a full SQL dump (not with export + import), this information would have been intact.

To fix things up you can create new passwords directly in the DB:

// MySQL
update users set user_hash = md5(‘newpass’) where user_name = ‘jim’;

Don’t forget to roll back those 777 permissions… :ohmy:

Wait, I could have installed a new instance and gotten a dump from the old one ? The old install was 7.8.5 and the new one is 7.10.10. That wouldn’t help the fact that I cannot add new users or get the user password email templates to work would it?

ugh, This is not getting any better. So far I have reinstalled SuiteCRM 3 times from scratch. in the installation instructions it gives chmod examples on what directories need to be chmod to what priviledges. I run those from the command line without any errors. I check the directories and they are what they are supposed to be. When I run the insall.php it complains that they aren’t writable. So I go back and chmod to 0777 just to get past that. At this point all I have working is “test Email” and one new user. When I try to setup Password Management for generating passwords and “Forgot Password” on the login, along with setting up password strength, etc. The save does nothing but kick me back to the admin page. Does everyone go through this headache? Sorry for the rant, getting frustrated… I wanted to have this done two days ago

The permissions don’t mean anything without the correct ownership. You’re probably using www-data for the chown command, while your actual web server user is a different one. The instructions explain this. Permissions problems will ruin your experience in a hundred different ways… so let’s try to get them right before anything else.

To explain your migration options - you can’t migrate between different versions, but you can install an older version, so you can do a full database migration, and only then upgrade to the latest.

Thanks pgr

Here is what I ran from a root login:

apachectl -S
[VirtualHost configuration:
*:80                   localhost (/etc/httpd/conf.d/http.conf:6)
*:443                  localhost (/etc/httpd/conf.d/https.conf:14)
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex cache-socache: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/run/httpd/" mechanism=default
PidFile: "/run/httpd/"
User: name="apache" id=48
Group: name="apache" id=48
[root@cq_simple_crm_server ~]#

I ran

chown -R apache:apache . In my CRM directory That directory has apache as the user and group. Looking through other directories I find user:group as php-fpm No idea where that is coming from. The server is a cloud server running Centos 7.

As far as migration The import/export is an option?


You need to get a better grasp of your current web-server configuration… confirm exactly if Apache is running as “apache:apache” or as “php-fpm:php-fpm” (probably this last one, since it appears without your intervention).

Try listing the possible apache processes and figure it out:

sudo ps -ef | egrep '(httpd|apache2|apache|fpm)' 

Another thing to check is if there is a second PHP engine running, normally this is coming from cron jobs. Try listing cron user by user:

sudo crontab -l -u apache
sudo crontab -l -u root
sudo crontab -l -u php-fpm
sudo crontab -l 

This last one might show a different crontab, called the “system-wide” crontab, depending on which Linux you’re running.

About the migration: I would always try a full migration before other options, because it would keep all my data, all my relationships, all users, etc. Only if I got into trouble with the full migration I would consider a more fragmented process moving data table by table, or with exports/imports.

Here is the PS results:

 ps -ef | egrep '(httpd|apache2|apache|fpm)'
root      1859     1  0 00:42 ?        00:00:02 /usr/sbin/httpd -DFOREGROUND
apache    1860  1859  0 00:42 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    1861  1859  0 00:42 ?        00:00:16 /usr/sbin/httpd -DFOREGROUND
apache    1863  1859  0 00:42 ?        00:00:15 /usr/sbin/httpd -DFOREGROUND
apache    1900  1859  0 00:42 ?        00:00:15 /usr/sbin/httpd -DFOREGROUND
apache    4762  1859  0 05:30 ?        00:00:08 /usr/sbin/httpd -DFOREGROUND
root      5685     1  0 Oct25 ?        00:00:44 php-fpm: master process (/etc/php-fpm.conf)
php-fpm   5686  5685  0 Oct25 ?        00:00:43 php-fpm: pool www
php-fpm   5687  5685  0 Oct25 ?        00:00:45 php-fpm: pool www
php-fpm   5688  5685  0 Oct25 ?        00:00:35 php-fpm: pool www
php-fpm   5689  5685  0 Oct25 ?        00:00:33 php-fpm: pool www
php-fpm   5690  5685  0 Oct25 ?        00:00:35 php-fpm: pool www
root      9480  9453  0 13:24 pts/0    00:00:00 grep -E --color=auto (httpd|apache2|apache|fpm)
php-fpm  27315  5685  0 Oct26 ?        00:00:31 php-fpm: pool www
php-fpm  32766  5685  0 Nov02 ?        00:00:17 php-fpm: pool www

No crontab listing for Apache
1 listing for root which is the one for the CRM
No other listings for Crontabs

In light of what you have told me regarding migrating the data, I think I will destroy this instance of this server, create a new one and install the version of SuiteCRM that I have working, do a dump of the db and then upgrade to the latest version. All after making sure it is working properly.

That looks like you have two web servers, or a web server with a php-fpm engine running under a different user. I doubt this is intentional, but it could be, if there are other groups set up for this to make sense. It sounds like a complicated web server set up.

If you go the route of setting up a new server, keep it simple, since you don’t seem comfortable with this sort of sysadmin job. A straight-forward Ubuntu + LAMP stack will work great for you.

When migrating, normally you need to consider moving:

  1. The full database
  2. The custom directory (if you have customizations)
  3. The upload directory, or the relevant parts of it (for stuff like attachments, photos, etc)
  4. Relevant settings from php.ini, config.php and config_overrride.php

Occasionally there might be a few other things, but they’re rare so I will assume you’re not using them.

Thanks pgr,

I thought I was comfortable enough to do this, didn’t seem to be that hard in the past… The two web servers is beyond me. I created another Centos7 instance, but I think I will go the Ubuntu route as you suggest. As I get older, simplier is the way to go.

I will follow your advice on migrating over and then updating.

Thanks again

This might help when installing Ubuntu

and here’s an updated version of the modules, in case you use PHP 7.2 instead:

apt install zip unzip iotop htop php-mbstring php7.2-mbstring php-gettext php-xml php7.2-zip php7.2-imap php7.2-gd php7.2-curl php-gd phpmyadmin 

The install of Ubuntu installed php 7.1 so I left it there.

I did a Sql dump of the DB and uploaded it to the server.
Copied the
Custom, and upload directories entirely, chmod to the proper user;group
copied config.php and config_override.php files also doing a chmod

So now I get the following when accessing the system:

Notice: Use of undefined constant JSON_LOOSE_TYPE - assumed 'JSON_LOOSE_TYPE' occurred in /var/www/html/CRM/include/utils.php on line 3913 [2018-11-06 16:05:11] display_stack_trace caller, file: /var/www/html/CRM/include/utils.php line#: 3413

I have a feeling I am doomed here on trying to restore the db this way.

So I made progress here! I moved the DB to the new server and used the module uploader to bring over my customizations from th eold system. Changed the DB name in the Config.php and I have all my info. Then I upgraded to 7.10.10 No errors. It appears that I have all my relationships and all working. I even can send emails (at least test ones. The last thing I have is th eemail templates for password management. I did a chown www-data:www-data . All my permissions are a 0755. Think I am still looking at a permissions for the email templates?

Sorry I don’t understand what your current issue is with the templates? Can you explain better (steps to reproduce, results you’re getting). Thanks

I really appreciate your help here believe me. Anyway, I got everything working with the exception of the email templates in the Password Management. Actually, two out of the are missing and if I try to create a new one it won’t save it. So if a user needs to have their password reset or does the request for password reset from the login we get the error that there is no template. I believe they went away AFTER I upgraded to 7.10.10. I set all permissions to 755 everywhere with the correct user:group. Can I just copy and paste them from the installation files of 7.8.5?

Looking further into the DB tables I see that the original table data is there, and the new templates I tried to make. I ran a repair relationships.

So, is it solved?

Maybe you have some security settings keeping certain users from accessing the Emails modules. Check Roles, Security Group composition, and the way Security Groups are assigned to records…

Not quite solved. The password management templates are not presented to be edited nor are they used for instance when a new user is created or requests for a password reset is revieved. Otherwise I think all is good.