Announcement

Collapse
No announcement yet.

Setting up Miva on nginx: unable to load configuration file

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Setting up Miva on nginx: unable to load configuration file

    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:

      Code:
      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:
      Code:
      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: [email protected]
    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:
    Code:
    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?

  • 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.
    David Carver
    Miva, Inc. | Software Developer

    Comment


    • 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)
      David Hubbard
      CIO
      Miva
      [email protected]
      http://www.miva.com

      Comment


      • 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: [email protected]
        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:

        Code:
        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?

        Comment


        • 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?
          David Carver
          Miva, Inc. | Software Developer

          Comment


          • 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.
            David Hubbard
            CIO
            Miva
            [email protected]
            http://www.miva.com

            Comment


            • 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: [email protected]
              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: [email protected]
              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
              Code:
              stdmodedatadir=/sites/dev.example.com/mivadata
              vs
              Code:
              stdmodedatadir=/var/www/sites/dev.example.com/mivadata
              However, adding the /var/www seemed to have no impact




              Comment


              • 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
                David Hubbard
                CIO
                Miva
                [email protected]
                http://www.miva.com

                Comment


                • 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:
                  Code:
                  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:
                  Code:
                  Error Code: MER-DBA-MYS-00001
                  Description: Unable to connect to database: Can't connect to local MySQL server through socket '/tmp/mysql.sock' &#40;2&#41;
                  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:
                  Code:
                  spawn-fcgi -p 8005 -n -- /var/www/sites/dev.example.com/cgi-bin/mivavm-v5.31/bin/mivavm_fastcgi-v5.31 &amp;
                  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:
                  Code:
                  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:
                  Code:
                  cp mivavm-v5.31/bin/mivavm_fastcgi-v5.31 ./mivavm
                  - I changed the spawn-fcgi command to:
                  Code:
                  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...)

                  Comment


                  • 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..

                    Comment


                    • 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.
                      David Hubbard
                      CIO
                      Miva
                      [email protected]
                      http://www.miva.com

                      Comment


                      • Originally posted by Mike521w View Post
                        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
                        David Hubbard
                        CIO
                        Miva
                        [email protected]
                        http://www.miva.com

                        Comment

                        Working...
                        X

                        This website uses cookies to identify visitors, track visitors to our website, store login session information and to remember your user preferences. By continuing to use this site you agree to our use of cookies. Learn More.

                        This website uses cookies. By continuing to use this site you agree to our use of cookies. Learn More.

                        Accept