[Stretch] Changing apache document root, php-fpm stops working

Discussion in 'Installation/Configuration' started by SergiX44, Jul 5, 2017.

  1. SergiX44

    SergiX44 Member

    I've recently created a clean installation of ispconfig on debian stretch, and i've a problem with php-fpm. Using the default document root it works without problems, but when i try to override the document root (for example for laravel installations) it stops to work, and show php as plain text. If i switch on fastcgi or mod php it back to work, but not fpm.
    This is how I override the document root in the apache directive box:
    Code:
    DocumentRoot {DOCROOT}/public
     
  2. SergiX44

    SergiX44 Member

    UPDATE:
    Put the full path, instead the DOCROOT it works:
    Code:
    DocumentRoot /var/www/clients/clientX/webX/web/public #working
    DocumentRoot {DOCROOT}/public #not working
    
    Can it be related to some ispconfig/apache settings? On my old Debian Jessie server work also the second one.
    Thanks
     
  3. SergiX44

    SergiX44 Member

  4. till

    till Super Moderator Staff Member ISPConfig Developer

    PHP-FPM is enabled for folders inside the web dir only, that's why it does not work when you set a folder outside of the web folder.
     
  5. SergiX44

    SergiX44 Member

    Ok, but the public dir is inside the web dir.
    The only difference between this
    Code:
    DocumentRoot /var/www/clients/clientX/webX/web/public #working
    DocumentRoot {DOCROOT}/public #not working
    Is that the second one is a symlink (generated by ispconfig). The second one, is working on debian jessie as I said, but not on stretch.
    I put those directives in the apache directives box on ispconfig, and the {DOCROOT} placeholder is not working, for override the document root (in that case, from web/ to web/public/)
     
  6. SergiX44

    SergiX44 Member

  7. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    wild guess, but when I check the templates, I see document_root all over the place adding its own slash so first of all you likely end up having
    {DOCROOT}//public

    en plus, it's used to determine where the cgi-bin, tmp...so on folders are located. Have no time to setup a test system for the changes to see what actually happens, sorry :(
     
  8. SergiX44

    SergiX44 Member

    No I've tested it. The only difference is that the first with the doc root placeholder and the second one the absolute path, is that the docroot use the symlink. I don't know why on jessie works but on stretch no
     
    Last edited: Oct 7, 2017
  9. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    php-fpm in jessie used mod_fastcgi ( at least I used that, it might have been fcgid though ) but on stretch it defnitly uses mod_proxy_fpm
    give me a sec, maybe I can spot something - currently setting up a test-vm, for another purpose but well... can't promise anything though
     
  10. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    have you tried leaving the docroot as it was before and instead using redirect option?
     

    Attached Files:

    Last edited: Oct 6, 2017
  11. SergiX44

    SergiX44 Member

    I need to change the document root for frameworks such Laravel, Yii, etc. The /public must be the docroot for security purposes.
     
  12. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    I know, using the redirect option everyone entering http://url.tld will end up beeing served by web/public while not seeing /public in their adressbar.
     
  13. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    just tried setting DocumentRoot {DOCROOT}/public in apache directive for a test site and... seems apache is defaulting after a Documentroot statement, might have changed in 2.4 dunno, haven't digged too much into that code :/ however didn't promise much and the redirect options seems to work as needed
     
  14. SergiX44

    SergiX44 Member

    I've fixed only using the absolute path to the docroot (/var/www/clients/clientX/webX/web/public). Using the redirect is not the right fix because security, and every request will be redirected, broking the routing system of those frameworks.
     
  15. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    hmm shouldn't these frameworks have an option to set their setup and public path?
    I'd setup this stuff in /private so you can use /web as supposed?
     
  16. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    left over possibilities:
    change /usr/local/ispconfig/server/conf/vhost.conf.master
    and copy/move <tmpl_var name='apache_directives'> to the top but below the original documentroot setting
    this could lead to other sites having issues when they try to overwrite instructions since they become first instead of last in conf

    copy generated vhost data from your sites-available/*.conf to the apache directives with your custom documentroot on top

    change document_root in web_domain table of dbispconfig database, don't forget to add corresponding cgi-bin/tmp folders ect.
    but this could lead to other issues with dunno what

    use proper code, if it can't be done by setting paths to use /private and /web your framework is 100% garbage
     
  17. SergiX44

    SergiX44 Member

    But this is the wrong approch, a dirty workaround for hosting only on ispconfig o_O
    You can rename the folder (https://laravel.com/docs/5.5/installation#installation), but the front controller must be in docroot.
    For example, on plesk there is an option for laravel, and that basically set the docroot in /public subfolder. This is a problem with fpm, because with fastcgi or mod_php works. This is problem about ISPConfig, because the {DOCROOT} placeholder, should put the real path, and not a symlink. You can't bend you application for the production server, is the opposite.
     
  18. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    see my previous post ;) and fpm is working totally fine, however getting a new docroot statement in conf leads apache to likely forget everything it was tough before for that vhost - it seems
     
  19. ztk.me

    ztk.me Well-Known Member HowtoForge Supporter

    https://laravel.io/forum/01-21-2015-laravel-5-modify-paths?page=1

    so set base to private and public to web, supposed way to properly configure it. That's what they say in your linked description aswell. Don't get confused by them using the term "public" as in publicly accessible and the folder named "public" which is reference only.
    https://laravel.com/docs/5.5/configuration
    https://laravel.com/docs/5.5/structure


    I understand why ppl use frameworks, because they are supposed to be easy but still it's nothing you just put somewhere and expect it to work. And I will stop here because I totally hate frameworks because of their yeah, feel free to PN me for an heated discussion on why frameworks usually suck :)
     
    Last edited: Oct 7, 2017
  20. SergiX44

    SergiX44 Member

    No, the apache directives is in the right place, because apache last DocumentRoot directive override the previous one, in-fact, the new document root is working, but php fpm and returns the index.php as plain text.
    If you switch to FastCGI, works.
    If you switch mod_php, works.
    The problem is with FPM.
    Not apache, it gets the docroot.
    FPM not works with the placeholder.

    The placeholder {DOCROOT} put something like that:
    Code:
    /var/www/example.com/web
    That is a symlink, and FPM not works, if override with that.
    Infact, if you look the default Document Root directive on top of the vhost, inserted by ISPConfig is with the real path:
    Code:
    /var/www/clients/clientX/webY/web
    So, why the ispconfig {DOCROOT} puts the symlink instead the real path?
    Again, if you put manually in the apache directives, instead using the placeholder, the realpath like ispconfig does, so:
    Code:
    DocumentRoot /var/www/clients/clientX/webY/web/the/folder/that/you/want
    It works.
    Is not framework problem, it's an ISPConfig on stretch configuration problem.

    Ok, but the problem is NOT about framework, it's about ISPConfig. I've some Laravel apps running on another server (as I said ISPC on Jessie, and Plesk on Centos) without problems.
    Simply it seems that the new mod_proxy_fcgi not supports symlinks. And this is a configuration problem of ISPConfig, not of the framework.
     
    Last edited: Oct 7, 2017

Share This Page