Setting up Miva on nginx: unable to load configuration file

[Mike521w]

We have a self-hosted Miva site running on an apache server, and we're changing to a server that runs nginx (with no apache). I'm not a server expert so I've been stumbling through the setup on the dev site, and I've progressed to having a site that does run .mvc files, but can't load the Miva config. I followed along with some of the messages in this thread, so our setup is very similar: https://www.miva.com/forums/forum/on...ing-in-fastcgi

1. I downloaded the Linux / FastCGI / x64 version of Empresa and ran through the setup. Our dev site started out as a straight copy of our live site (which works), and it has a cgi-bin folder with engine v5.31, so in general I proceeded as if I was upgrading the engine (unzip some files, copy some files and folders, change the config file, rename/backup the old files, rename the new files to replace the old files). So far so good, I've done this before when upgrading from 5.2x to 5.31 on the apache server
2. I added the following blurb to our nginx config:
   
   

   location ~ \.mvc$ {
   	        fastcgi_read_timeout    300;
   	        fastcgi_pass            dev.example.com:8005;
   	        fastcgi_param           MvCONFIG_LIBRARY /var/www/sites/dev.example.com/cgi-bin/libmivaconfig.so;
   	        include                 fastcgi_params;
   	    }

3. I ran the command:
   

   spawn-fcgi -p 8005 -n -- /var/www/sites/dev.example.com/cgi-bin/mivavm-v5.31/bin/mivavm_fastcgi-v5.31 &

4. I uploaded diagtool.mvc for testing

Now when I visit diagtool.mvc I get the following message:

Configuration Error: Error loading configuration library: Unable to locate configuration file
Please contact the server administrator: webmaster@localhost

This is progress - before getting Empresa running I was getting 502 errors. So the question is why are we getting this configuration file error now? The config file is definitely in the directory specified in the nginx config (step 2 above). And that file is just a copy of cgi-bin/mivavm-v5.31/lib/config/3x.so, so I tried changing the nginx config like so:

fastcgi_param           MvCONFIG_LIBRARY /var/www/sites/dev.example.com/cgi-bin/mivavm-v5.31/lib/config/3x.so;

But after updating the ownership of 3x.so to root:root and giving it 4755 permissions (same as the libmivaconfig.so copy), I was back to getting the same error as before.

Can anyone point me in the right direction?

[dcarver]

The issue is the mivavm_fastcgi-v5.31.conf configuration file cannot be found. Where is that file located? It needs to either be where the binary is located, where the libmivaconfig.so is located, or in /etc.

[ILoveHostasaurus]

Additional to what David posted, nothing should be set 4755; that's not a secure thing to do and shouldn't be necessary either way. Sounds like you just need what may have been mivavm.conf in a traditional non-FastCGI setup, named mivavm_fastcgi-v5.31.conf in your FastCGI setup, in the same directory as the binary (assuming the 3x.so is being used as the libmivaconfig.so)

[Mike521w]

Thank you both, I didn't have a mivavm_fastcgi-v5.31.conf file - I had mivavm.conf. Still having trouble though.. I copied mivavm.conf as mivavm_fastcgi-v5.31.conf and uploaded to cgi-bin (which is where mivavm lives). No luck, so I tried changing ownership to root:root, still no luck. Then I made another copy of it in cgi-bin/mivavm-v5.31/lib/config/ but still no luck.

Finally I copied to /etc - still not working, but the error message changed:

Configuration Error: The configured script directory is not an absolute path
Please contact the server administrator: webmaster@localhost

I double-checked the conf file, it doesn't say anything about a script directory - maybe I have to add a line? Here are the contents:

mivaroot=&[document_root]
stdmodedatadir=/sites/dev.example.com/mivadata
openssl=/usr/lib64/libssl.so.1.0.0d
openssl_crypto=/usr/lib64/libcrypto.so.1.0.0d
#cadir=/sites/dev.example.com/cgi-bin/mivavm-v5.31/certs/openssl-1.0
cafile=/etc/ssl/certs/ca-bundle.crt
builtindir=/sites/dev.example.com/cgi-bin/mivavm-v5.31/lib/builtins

securityoptions=15

<DATABASE-LIB METHOD="MivaSQL" LIBRARY="/sites/dev.example.com/cgi-bin/mivavm-v5.31/lib/databases/mivasql.so">
<DATABASE-LIB METHOD="MySQL" LIBRARY="/sites/dev.example.com/cgi-bin/mivavm-v5.31/lib/databases/mysql.so">

<SYSTEM-LIB CODE="GD" LIBRARY="/usr/lib64/libgd.so.2">

globaltimeout=0

About the 4755 permissions, I had stumbled onto this post in the knowledgebase (https://support.miva.com/supportsuit...y-uid-mismatch) - didn't notice that it's from 2009 though.. What should I change the permissions to instead?

[dcarver]

The .so file should probably be 0644. What is the document_root environment variable set to? That value needs to be an absolute path. Can you change the mivaroot directive to use the a hard coded path such as /var/www/html?

[ILoveHostasaurus]

This made me curious:

fastcgi_param MvCONFIG_LIBRARY /var/www/sites/dev.example.com/cgi-bin/libmivaconfig.so;

For your setup, is the libmivaconfig.so that you're using based on the env.so or 3x.so file? The env.so is when you're choosing to use environment variables to give Empresa its configuration, while 3x.so is for when using the text file for it to load its config. If using 3x.so, then Empresa will expect the conf file to be present in the same directory as the binary, with a name matching the binary's name followed by a .conf suffix. If you're using env.so then disregard what was sent previously as the config file won't be consulted regardless of location. I have a feeling you are using 3x.so given the error changed when you moved the file to /etc, but just wanted to add this note on the off chance that isn't the case.

Next question; since you're using the fastcgi version, did you kill Empresa and have your process spawner start a new copy after altering the config file?

Now, expanding on what David Carver sent; this:

mivaroot=&[document_root]

would only work if something is actually setting that environment variable. Apache with suexec does this, but nginx and/or the software you're using to spawn the fastcgi processes may not. You may be able to make them do so, allowing you to use the config file without hard coding the path to the document root, but if this config is site specific, you could also just hard code it and not worry about trying to set the variable. Since you have other hard coded paths in there, probably best to just do the same for that directory.

On that article you found, I'm going to remove it after replying to this. That article is missing some very important context in that the only time Empresa would be used with that type of configuration is with a dated setup where one copy of Empresa is intended to be used for multiple websites on the same server, all running as different user id's. In that scenario, Empresa must be setuid to allow it to change the effective user depending on which site it's handling requests for.

[Mike521w]

More progress!! Thank you both again,

You're correct, I was using 3x.so as my cgi-bin/libmivaconfig.so. So I did the following:

- changed file perms to 0644
- I wasn't sure which conf file was in use (cgi-bin/mivavm.conf vs cgi-bin/mivavm_fastcgi-v5.31.conf) so I did some testing and it looks like changes in regular mivavm.conf are ignored, but changes in the fastcgi one are used)
- hardcoded mivaroot in the conf file: mivaroot=/var/www/sites/dev.example.com/html
- killed Empresa (as it turned out there were two instances running, guess I ran the spawn command twice)
- restarted Empresa

New error:

Configuration Error: Miva is running in server safe mode but no authfile or authuserdir are defined
Please contact the server administrator: webmaster@localhost

I googled that and surprisingly came up with absolutely nothing.. Did some more googling looking for info on authfile or authuserdir and landed on this page (https://support.miva.com/supportsuit...t-v400-package), which seemed to indicate that I could point authuserdir to the mivadata directory. So I tried:

authuserdir=/sites/dev.example.com/mivadata

To my surprise, the error changes to:

Configuration Error: The configured data directory does not exist
Please contact the server administrator: webmaster@localhost

It's susprising because that directory does exist.. Maybe a permissions thing? And why didn't it give that error before? Anyway that's where I'm at.. making progress but still stuck :/

Sidenote, I noticed that my conf file has paths that look like they should be absolute, but aren't, for example

stdmodedatadir=/sites/dev.example.com/mivadata

vs

stdmodedatadir=/var/www/sites/dev.example.com/mivadata

However, adding the /var/www seemed to have no impact

[ILoveHostasaurus]

The path should be absolute from the perspective of the executing Empresa, so if you're launching it in a way that has visibility to /var/www... then that is what should be in there. If you're launching it in a way that chroot's it, is in a container, etc., then the path would be the full absolute path to the directories that would start at whatever root is to it.

I've never seen that server safe mode error, and am actually not sure what tells Empresa it's running in that mode. I suspect it may think that is the case if root has executed it, which you really never want to do. I'd get rid of the authuserdir directive and make sure you're launching Empresa fastcgi as the user associated with the site in question; i.e. the one that owns all the web files and mivadata files. What method of launching the fastcgi are you using?

We typically use either Apache for that if it's a situation where Apache can't be gotten rid of, or the spawn-fcgi from lighttpd: https://redmine.lighttpd.net/projects/spawn-fcgi/wiki

[Mike521w]

It works!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Almost... diagtool.mvc works perfectly, but admin.mvc and merchant.mvc give errors about connecting to the database. I checked with a PHP script though, the database name and login credentials are the same as the prior server. Maybe there's something else I need to configure? The errors are:

admin.mvc:

Error Code:MER-ADM-00003
Description:Miva Merchant has not been initialized. Please use the Miva Merchant Setup script to initialize the required data files.

merchant.mvc:

Error Code: MER-DBA-MYS-00001
Description: Unable to connect to database: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

I looked through all the tests in diagtool and all are pass. The only odd thing is that s.miva_sslavailable is 0 - even though an SSL is installed and I'm loading the diagtool through https with no problem.

Any thoughts? Is it time to contact the host and have them let Miva connect to the DB? I don't know how Miva connects.. I do have SSH/root access though so if there's a command or two I can probably handle it

In answer to the fastcgi method (and this is what got the ball rolling on getting it working) I'm using spawn-fcgi as well, but I was logged in as root when running:

spawn-fcgi -p 8005 -n -- /var/www/sites/dev.example.com/cgi-bin/mivavm-v5.31/bin/mivavm_fastcgi-v5.31 &

Looking at that command more closely made me realize I was running the wrong mivavm (or at least, I was making things more confusing for myself by running that one). So I did the following:

- I did a recursive chown from within the cgi-bin directory so everything would be owned by the same user:group as nginx, because as it was everything was inconsistent, some was root, some was the nginx user, etc:

chown -R nginxuser:nginxgroup ./*

- I realized my spawn-fcgi was loading the mivavm from cgi-bin/mivavm-v5.31/bin/mivavm_fastcgi-v5.31, which is what led to all my confusion with which .conf file was being used. So I made a fresh copy of that file over to cgi-bin:

cp mivavm-v5.31/bin/mivavm_fastcgi-v5.31 ./mivavm

- I changed the spawn-fcgi command to:

runuser -l nginxuser -c 'spawn-fcgi -p 8005 -n -- /var/www/sites/dev.example.com/cgi-bin/mivavm &'

- now it's running cgi-bin/mivavm and using cgi-bin/mivavm.conf, all as the same user as nginx
- and finally I changed the paths in mivavm.conf to be absolute from the server root (/var/www/sites...)

[Mike521w]

Update: I realized there's a merchdb.dat file, took a look at mine and it's using a different DB username than I used in my test PHP script. I'm guessing this user wasn't copied over to the new server, or it has a new password, and that if I manually update this file, all will be good

I contacted my host and asked them to copy the user over - I'm guessing it'll have a new password. If that's the case, how can I properly encrypt the password and put it into merchdb.dat? Right now the existing password is ENC2:asdfasdf... Can I manually run the new password through an encrypting tool of some sort? I don't think this is just base64..

[ILoveHostasaurus]

Both of the admin/merchant errors are likely just related to not being able to connect to the database. If your merchdb.dat file uses 'localhost' as the server, Empresa will attempt to use a socket connection instead of TCP. You could get around that by using 127.0.0.1 but if the database actually is local, socket will be better performance. Most likely, you're running on a server with systemd managing processes, and it hides each daemon's temporary files in a unique subdirectory of /tmp, which causes problems for the socket file. The two ways around this are to set your database to keep the socket file somewhere other than tmp that your site user also has access to, or edit what is likely a systemd file already present to tell it to not use a private temporary space for mysql/mariadb.

If this is CentOS 7 for example, you'd edit /etc/systemd/system/multi-user.target.wants/mariadb.service and set PrivateTmp=false, then restart mariadb. It will then begin putting the socket file in the real /tmp where Empresa will see it.

Now, in general, I'd recommend you not have nginx and your site user be the same UID. Ideally you'd want nginx running as some unprivileged user with read access to just your example.com/html/ directory, i.e. document root, so it can serve the static content. Then you have your mivadata directory, cgi, and Empresa running as a site-specific user, which is also the user all the site content is owned by. mivadata should be 700 so only that site user can get in. Static requests, no problem, nginx reads and serves the files. Merchant requests, nginx sends it to the fastcgi, fastcgi Empresa is running as the site user which has permission to the mivadata directory, does its thing, outputs the content.

[ILoveHostasaurus]

Update: I realized there's a merchdb.dat file, took a look at mine and it's using a different DB username than I used in my test PHP script. I'm guessing this user wasn't copied over to the new server, or it has a new password, and that if I manually update this file, all will be good

I contacted my host and asked them to copy the user over - I'm guessing it'll have a new password. If that's the case, how can I properly encrypt the password and put it into merchdb.dat? Right now the existing password is ENC2:asdfasdf... Can I manually run the new password through an encrypting tool of some sort? I don't think this is just base64..

In your store admin do a search for PA-DSS and go to the pa-dss checklist page. Launch the wizard tool at the bottom and just step through it taking all the defaults. It should re-encrypt what's in merchdb.dat

[Mike521w]

Thank you again for the help with this, and sorry for the delayed response here - haven't had time to work on this at all in the past week!

Our host changed the location of the socket file and we restarted mysql, mivavm and nginx, but Miva is still looking in /tmp for the .sock file. How can I tell it to use the new one (/var/lib/mysql/mysql.sock)? Changing merchdb.dat to 127.0.0.1 works just fine, but I'd rather use localhost since that's better

Also there's a new issue - when changing to 127.0.0.1 it looks like I should be able to log in to Miva admin. I've changed my hosts file and we have an SSL installed on the dev server, so everything looks exactly like the live site. However, it kicks me back to the login screen, just like it does if I'd entered the wrong password. We have phpMyAdmin set up, so I can edit the DB directly, but I can't view or change my password since it's encrypted. My login should work though, this DB is just a direct copy of the one on the live site. Is there any way to determine why the login fails? I do see that the t_fails and c_fails columns of the Users table have been getting incremented every time I fail to log in, so that's good news.

Meanwhile the merchdb.dat file issue is now fixed. The user that miva used to connect to mysql hadn't been created on the new server, and I was using a different user for my test PHP script. I incorrectly assumed the miva user had been recreated with the same password. So our host re-created the miva user with a new password, which I added to merchdb.dat, unencrypted for now. As soon as we get Miva connected to the DB and I can log in to the admin, I'll run through the encryption process.

[ILoveHostasaurus]

The Empresa mysql.so library has the socket hard coded to /tmp/mysql.sock because the library is statically compiled. So, at this point in time, the socket location can't be altered.

Regarding the Users incrementing the t_fails; that at least tells us you're talking to the right db and it's finding the correct username. The encryption specific to just the Users table (i.e. not Orders) is not server specific but could have issues if the OpenSSL version between servers differs by a large amount; could that be the case?

[Mike521w]

Hmm I ran 'openssl version' on each server and both returned the same thing: "OpenSSL 1.0.1e-fips 11 Feb 2013". Since I have access to the DB, I tried just changing the password field to 'asdfasdf' but I still couldn't log in (t_fails was incremented again). I was thinking if it worked I would change the password as soon as I was able to log in..

About the socket, do you think I can get away with a symlink from /tmp/mysql.sock to /var/lib/mysql/mysql.sock? Seems something along those lines was used in this thread from way back in 2007: https://www.miva.com/forums/forum/de...a-mysql-misery