File Permissions, Ownership and Nobody

Discussion in 'Linux VPS/Dedicated - cPanel' started by chaddro, Apr 18, 2009.

  1. chaddro

    chaddro New Member

    Having a little trouble with tech support, so I just wanted to verify my understanding here. I am a unix noob, so please be patient with me :rolleyes:!

    To make a LOOOONG story short: Tech recompiles apache to enable FastCGI so I could also use xcache. But now I'm getting "permissions" problems in magento, and Internal 500 server errors. More back and forthing with tech, but the server was never stable and was repeatably throwing Internal Server Errors (with and without xcache loaded). I finally give up on FastCGI and xcache (boy was it faster, but even the xadmin.php script was throwing internal 500 errors!) and set the server back to dso with suExec.

    But now I'm having many problems with file permissions in magento and my test installs were all pretty much broken. More back and forth, no real answer as to why, but now I have to set some folders to 777. This fixed some of the problems, but perl update scripts were still failing. To fix this ALL files and folders had to be 777 :eek:. If they aren't then the perl scripts were failing because they could not over write the files. Can't upload files from dreamweaver anymore.

    MORE digging... I find a post saying to run su_exec("id"); my server returns:
    uid=99(nobody) gid=99(nobody) groups=99(nobody)

    Shouldn't these by my account id? This gives me an idea...

    I SSH in and chown -R nobody:nobody * on one of my magento directories.... now pearl works, ... but to upload with dreamweaver I now have to use my root account and password!!

    This seems horribly insecure to me. I try su_exec("id") on my bluehost shared server (that is running fastcgi just fine) and it returns:

    uid=780(chicagp0) gid=781(chicagp0) groups=781(chicagp0)

    All files are owned by chicagp0:chicagp0 and permissions are files 644 folders 755 and pearl works just fine.

    So what should I do? If I wasn't such a noob, I'd recompile apache myself, but I haven't a clue where to start. And I really need an opcode cacher to improve the performance on magento.... I suppose LiteSpeed is out of the quest...

    Sorry this is so long winded, but you have no idea how many hours I've put into this. Would appreciate some advice/confirmation that the server is still not correct and how best to proceed.

    Tech support seems pretty worn out over this, they must have recompiled apache 4 times (once to enable FastCGI; opps, forgot curl; again for a mystery issue; and AGAIN at my request to put back the way it was (but obviously isn't). They probably think I'm nuts or being too picky.

    HELP?!
     
  2. Dan

    Dan Moderator

    Wow chaddro, feel the pain

    I've looked at a couple of Magento tutorials to install it onto cPanel and none of them said anything about requiring fastCGI or Xcache.

    My suggestion would be to start all over. Wipe the whole install and database and start from scratch. If you are using SSH do NOT log in as root. If you are uploading files by FTP do NOT log in as root. If your problems are with permissions then log in as the user that should HAVE the permissions. Get it working as is and THEN start making changes.

    The 500 errors are simply permissions errors. It doesn't mean the server has internal problems ;)

    Hope that helps
     
  3. chaddro

    chaddro New Member

    Hi Dan,

    Yes, I have done this numerous times. Magento has always been picky about permissions, but I have been installing and testing it since .6 beta 18 months ago. I never had this much trouble with it. The way the system is now I have to set all files and folders to 777 in order for the pear scripts to update since they not only overwrite php files but also css and images.

    Magento's "Connect Manager" lets you remote update/install/uninstall packages from the back end. If you're running magento 1.1.6, you can "check for update" and "install all". You can also install other features and user contributed packages. This is very handy because the scripts wget's the remote file and unpackages them to a temp directory, if this goes without error, they are then moved into the proper structure of the store over writing older version if necessary. This will no longer work since tech support recompiled apache.

    Concerning FastCGI. I have no idea why when this was activated the server kept throwing Internal 500 errors. You cant blame that on Magento either. It was happening in the xcache.php admin, and randomly as you browsed the main company site which is running on zencart.

    Someone at webhostingreview comment that FastCGI often needs to be "hand tweeked" to run properly. I wouldn't know where to begin.

    Here are the commands I use in SSH to install Magento (logged in as USER not ROOT):

    wget http://www.magentocommerce.com/downloads/assets/1.1.8/magento-1.1.8.tar.gz
    tar -zxvf magento-1.1.8.tar.gz
    mv magento/* magento/.htaccess .
    chmod o+w var var/.htaccess app/etc
    chmod -R o+w media
    ./pear mage-setup .
    ./pear install magento-core/Mage_All_Latest
    rm -rf downloader/pearlib/cache/* downloader/pearlib/download/*

    It is also my understanding that if the server is running suPHP/suEXEC that you do not need to set permissions to '777'. Tech again asserts that suExec is installed and running correctly, but how could it be if I have to use 777?

    On top of this my Cron job is reporting:
    /dev/zero: No space left on device
    Failed creating file mapping

    -frazzled
     
  4. Dan

    Dan Moderator

    Hiya Frazzled :)

    Ok I may have found something here. Here is a post on installing using SSH and here is a post not using SSH. Both of those posts state if you are using suexec AND suphp then you do not need to set permissions but I only see you saying your system is running suxec. That would cause problems like what you are seeing since, as I understand it, the 'su' part is switch user meaning apache (suexec) and php (suphp) when ran will run as the user.

    To check to see if suPHP is enabled log into WHM and go to Service Configuration >> Apache Configuration >> Configure Suexec and PHP. There you should see that the PHP 5 handler is set to suphp and that Apache suexec is set to on.

    I have no idea about the the cronjob error but I would say with permissions not working correctly you're going to see all kinds of errors.

    Hope that helps
     
  5. chaddro

    chaddro New Member

  6. chaddro

    chaddro New Member

Share This Page