Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 9 of 9
  1. #1
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    PHP Not Working in Sub Directories

    Today I installed LAMP onto my computer. The install went smoothly. The home directory for Apache2 and PHP is: /var/www/html

    In the html (root) directory everything works perfectly, including PHP. However PHP does not function in any sub directory of the html directory.

    Basically, what I want is for PHP to simply work Globally within any sub directory I create to the html directory. And I would like to achieve this without having to create new paths or permissions each time I create a new sub directory that may contain a PHP file that needs to execute. In other words just like a web hosting account works.

    You would think a simple configuration in either the apache2.config or php.ini files would do the trick, but I have searched the web hopelessly only to find numerous grossly complicated replies that I could not begin to understand and none of which provided a "global" answer.

    I am not a server side programmer, though I am a web developer, so I would appreciate that any answers are spelled out in baby terms for dummies (me). Thank you.

  2. #2
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 480 Times in 468 Posts
    LAMP is a decidedly vague description. Which flavor of Linux? How did you configure/install things? Where did you install them? How are you telling Apache where to (and not to) run PHP? What's your httpd.conf look like? Are you using a pre-built?
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  3. #3
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I am running Linux Mint 18. Lamp stands for (L) Linux, (A) Apache, (M) MySQL, (P) PHP, Perl, Python. LAMP is a package that installs all 4 into Linux Mint with one command all pre-configured to work together properly. This is why they all recognize and work properly in the home directory of: /var/www/html

    So as you asked, I did not need to configure Apache where to run, or not to run anything. It is all properly preconfigured to begin with, again as verified that everything works properly in the home directory.

    In the latest version of Apache2 for Linux Mint 18 the httpd.conf file is now called apache2.conf. I am pasting that files contents below for your reference. Thank you

    # This is the main Apache server configuration file. It contains the
    # configuration directives that give the server its instructions.
    # See Apache HTTP Server Version 2.4 Documentation - Apache HTTP Server Version 2.4 for detailed information about
    # the directives and /usr/share/doc/apache2/README.Debian about Debian specific
    # hints.
    #
    #
    # Summary of how the Apache 2 configuration works in Debian:
    # The Apache 2 web server configuration in Debian is quite different to
    # upstream's suggested way to configure the web server. This is because Debian's
    # default Apache2 installation attempts to make adding and removing modules,
    # virtual hosts, and extra configuration directives as flexible as possible, in
    # order to make automating the changes and administering the server as easy as
    # possible.

    # It is split into several files forming the configuration hierarchy outlined
    # below, all located in the /etc/apache2/ directory:
    #
    # /etc/apache2/
    # |-- apache2.conf
    # | `-- ports.conf
    # |-- mods-enabled
    # | |-- *.load
    # | `-- *.conf
    # |-- conf-enabled
    # | `-- *.conf
    # `-- sites-enabled
    # `-- *.conf
    #
    #
    # * apache2.conf is the main configuration file (this file). It puts the pieces
    # together by including all remaining configuration files when starting up the
    # web server.
    #
    # * ports.conf is always included from the main configuration file. It is
    # supposed to determine listening ports for incoming connections which can be
    # customized anytime.
    #
    # * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/
    # directories contain particular configuration snippets which manage modules,
    # global configuration fragments, or virtual host configurations,
    # respectively.
    #
    # They are activated by symlinking available configuration files from their
    # respective *-available/ counterparts. These should be managed by using our
    # helpers a2enmod/a2dismod, a2ensite/a2dissite and a2enconf/a2disconf. See
    # their respective man pages for detailed information.
    #
    # * The binary is called apache2. Due to the use of environment variables, in
    # the default configuration, apache2 needs to be started/stopped with
    # /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not
    # work with the default configuration.


    # Global configuration
    #

    #
    # ServerRoot: The top of the directory tree under which the server's
    # configuration, error, and log files are kept.
    #
    # NOTE! If you intend to place this on an NFS (or otherwise network)
    # mounted filesystem then please read the Mutex documentation (available
    # at <URL:http://httpd.apache.org/docs/2.4/mod/core.html#mutex>);
    # you will save yourself a lot of trouble.
    #
    # Do NOT add a slash at the end of the directory path.
    #
    #ServerRoot "/etc/apache2"

    #
    # The accept serialization lock file MUST BE STORED ON A LOCAL DISK.
    #
    Mutex file:${APACHE_LOCK_DIR} default

    #
    # PidFile: The file in which the server should record its process
    # identification number when it starts.
    # This needs to be set in /etc/apache2/envvars
    #
    PidFile ${APACHE_PID_FILE}

    #
    # Timeout: The number of seconds before receives and sends time out.
    #
    Timeout 300

    #
    # KeepAlive: Whether or not to allow persistent connections (more than
    # one request per connection). Set to "Off" to deactivate.
    #
    KeepAlive On

    #
    # MaxKeepAliveRequests: The maximum number of requests to allow
    # during a persistent connection. Set to 0 to allow an unlimited amount.
    # We recommend you leave this number high, for maximum performance.
    #
    MaxKeepAliveRequests 100

    #
    # KeepAliveTimeout: Number of seconds to wait for the next request from the
    # same client on the same connection.
    #
    KeepAliveTimeout 5


    # These need to be set in /etc/apache2/envvars
    User ${APACHE_RUN_USER}
    Group ${APACHE_RUN_GROUP}

    #
    # HostnameLookups: Log the names of clients or just their IP addresses
    # e.g., Welcome to The Apache Software Foundation! (on) or 204.62.129.132 (off).
    # The default is off because it'd be overall better for the net if people
    # had to knowingly turn this feature on, since enabling it means that
    # each client request will result in AT LEAST one lookup request to the
    # nameserver.
    #
    HostnameLookups Off

    # ErrorLog: The location of the error log file.
    # If you do not specify an ErrorLog directive within a <VirtualHost>
    # container, error messages relating to that virtual host will be
    # logged here. If you *do* define an error logfile for a <VirtualHost>
    # container, that host's errors will be logged there and not here.
    #
    ErrorLog ${APACHE_LOG_DIR}/error.log

    #
    # LogLevel: Control the severity of messages logged to the error_log.
    # Available values: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the log level for particular modules, e.g.
    # "LogLevel info ssl:warn"
    #
    LogLevel warn

    # Include module configuration:
    IncludeOptional mods-enabled/*.load
    IncludeOptional mods-enabled/*.conf

    # Include list of ports to listen on
    Include ports.conf

    # Sets the default security model of the Apache2 HTTPD server. It does
    # not allow access to the root filesystem outside of /usr/share and /var/www.
    # The former is used by web applications packaged in Debian,
    # the latter may be used for local directories served by the web server. If
    # your system is serving content from a sub-directory in /srv you must allow
    # access here, or in any related virtual host.
    <Directory />
    Options FollowSymLinks
    AllowOverride None
    Require all denied
    </Directory>

    <Directory /usr/share>
    AllowOverride None
    Require all granted
    </Directory>

    # Options Indexes FollowSymLinks

    <Directory /var/www/>
    Options ExecCGI FollowSymLinks IncludesNOEXEC Indexes SymLinksIfOwnerMatch
    AllowOverride All
    Require all granted
    </Directory>


    <Directory /srv/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
    </Directory>


    # AccessFileName: The name of the file to look for in each directory
    # for additional configuration directives. See also the AllowOverride
    # directive.
    #
    AccessFileName .htaccess

    #
    # The following lines prevent .htaccess and .htpasswd files from being
    # viewed by Web clients.
    #
    <FilesMatch "^\.ht">
    Require all denied
    </FilesMatch>


    #
    # The following directives define some format nicknames for use with
    # a CustomLog directive.
    #
    # These deviate from the Common Log Format definitions in that they use %O
    # (the actual bytes sent including headers) instead of %b (the size of the
    # requested file), because the latter makes it impossible to detect partial
    # requests.
    #
    # Note that the use of %{X-Forwarded-For}i instead of %h is not recommended.
    # Use mod_remoteip instead.
    #
    LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
    LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %O" common
    LogFormat "%{Referer}i -> %U" referer
    LogFormat "%{User-agent}i" agent

    # Include of directories ignores editors' and dpkg's backup files,
    # see README.Debian for details.

    # Include generic snippets of statements
    IncludeOptional conf-enabled/*.conf

    # Include the virtual host configurations:
    IncludeOptional sites-enabled/*.conf

    # vim: syntax=apache ts=4 sw=4 sts=4 sr noet
    Include /etc/phpmyadmin/apache.conf

  4. #4
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 480 Times in 468 Posts
    Quote Originally Posted by eharris View Post
    I am running Linux Mint 18.
    Part of the clarification I wanted, since whilst yes:

    Quote Originally Posted by eharris View Post
    Lamp stands for (L) Linux, (A) Apache, (M) MySQL, (P) PHP,
    Is still decidedly vague given that not all Linux flavors or their packages install things in the same place. Mostly it depends on what legacy they came from -- Red Hat, Debian, Suse, or Slack. Likewise are you actually using mysql, or are you using mariadb which has replaced it in most distro's? Which PHP? 5.6? 7.0? 7.2? They all have different quirks. Whilst LAMP does mean those things, each of those things could have dozens if not hundreds of different versions/flavors/oddities. What goes for a Debian/Ubuntu base can be utter and complete gibberish on Red Hat/Fedora/CentOS. PHP7 sucks with fastCGI and often fails outright if the URI's get too complex.

    It's actually one of the biggest problems with Linux -- the endless options and forks of projects none of which are on the same bloody page as each-other; every fork up and deciding to ignore what came before it so there's little to no standardization. (Mind you, that's also an advantage! CHOICES!)

    Usually out of box with Mint (Based on ubuntu, which is just Debian in drag) the /var/www/html directory is the fallback that allows no subdirectory access/execution for security reasons. Until you set up a domain with it's own /var/www/domainName/web directory, you won't have proper access to it. Usually I go through and install something like ISPConfig just to take the headaches out of that since this is 2019 so there's no reason to be dicking around with config files for something so mundane. I wanted to play those games, I'd drag the Trash-80 Model 12 out of storage and boot up Xenix!

    Pretty much until you set up a virtualHost I don't think it's going to let you do much more.

    Also though which CGI/FP interfaces did you set up? Did you go with PHP-FPM? FastCGI? Depending on which is in place it too can effect how access is restricted/not restricted. Again why I prefer to just toss ISPConfig in to handle the nitty-gritty of that.

    When you installed PHP, Apache, and so forth, what EXACTLY did you apt-get? Did you miss any of the dozens of dependencies?
    Last edited by deathshadow; Feb 5th, 2019 at 09:34 PM.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  5. #5
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Thanks for your reply. I see you are out of Keene, NH. I am out of Marlborough, right next to Keene! LOL, I wonder if I know you.

    I really can't answer many of your questions. Basically all I needed to do was enter one sudo command line, and the whole thing installed smoothly. There was absolutely no configuration required in PHP, Apache, and so on. No changes to the config files. Just automated. So I did not deal with dependencies or any of the other configurations you had mentioned. Are you a Keene business owner? If that is the case I could actually show the the laptop. If you didn't mind of course. You are much more knowledgeable that I.

  6. #6
    Senior Coder CFMaBiSmAd's Avatar
    Join Date
    Oct 2006
    Location
    Denver, Colorado USA
    Posts
    4,257
    Thanks
    3
    Thanked 553 Times in 538 Posts
    Define: "PHP does not function in any sub directory of the html directory."

    What symptom or error are you getting that leads you to believe something isn't working and what exactly did you do leading up to trying to get php to function in a sub-directory?

    What exact, including capitalization, url are you entering in your browser? What exact path and file name, including capitalization, is the php file at? What exact php code, including the php opening tags, is in the file(s)?
    Finding out HOW to do something is called research, i.e. keep searching until you find the answer. After you attempt to do something and cannot solve a problem with it yourself, would be when you ask others for help.

  7. #7
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 480 Times in 468 Posts
    I used to have a shop here in Keene 20 years ago, but I liquidated it to pay a friends medical bills. (Long story)

    Right now I freelance web dev out of my duplex.

    I don't have a lot of hands-on time with Mint, but after a quick research I assume you did "apt-get install lamp-server" a preconfigured package that really isn't pre-configured what I would treat as being "properly" set up. You are likely missing dozens of dependencies and interactions betwixt PHP and Apache since Christmas only knows what it set up -- or didn't set up -- for the configuration. What PHP version? Is it my or maria? Did they secure it with fail2ban?

    There's a reason my apache install on Debian typically reads more like this:

    Code:
    apt-get -y install apache2 apache2-doc apache2-utils libapache2-mod-php php7.0 php7.0-common php7.0-gd php7.0-mysql php7.0-imap phpmyadmin php7.0-cli php7.0-cgi libapache2-mod-fcgid apache2-suexec-pristine php-pear php7.0-mcrypt mcrypt  imagemagick libruby libapache2-mod-python php7.0-curl php7.0-intl php7.0-pspell php7.0-recode php7.0-sqlite3 php7.0-tidy php7.0-xmlrpc php7.0-xsl memcached php-memcache php-imagick php-gettext php7.0-zip php7.0-mbstring memcached libapache2-mod-passenger php7.0-soap
    .. and from there I still typically have to run a few a2enmod to enable specific apache optional features, edit the proxy.conf, etc, etc.

    But then I tend to do servers, and it sounds like you're trying to set up a testing environment on a desktop linux install. You'd THINK that would be easier than windows, it usually isn't since little is properly pre-configured and you end up having to spend hours dicking around on the command line for the simplest of things.

    There's a reason Windows is for desktops and Linux is for servers, and those who cross that line usually end up with egg on their face. Particularly given what a insecure unstable mess Windows is as a server, and how pathetically crippled and useless *nix flavors are on the desktop.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  8. #8
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    The issue has been resolved. The answer came in the form of piecing together answers and help from 3 different sources.

    First, deathshaddow above mentioned "until you set up a virtualHost I don't think it's going to let you do much more."

    I believed he was right so I went to the web in search of how to set up a virtual host. I found two different video tutorials:

    Creating Virtual Hosts in LAMP (Apache2) to Host Multiple Websites - Bing video
    https://www.bing.com/videos/search?q...C&&FORM=VRDGAR

    The above video was very helpful, but actually did not work. The only reason it did not work is that he left out two things in the video. First, to name the file you create in the Apache2 directory with a .conf at the end. And secondly he left out setting permissions on the new directory you create in the var/www/newdirectory

    If you watch the above video and then add what I just included all works fine. Thank you to all, and particularly to deathshaddow.

  9. #9
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 480 Times in 468 Posts
    Directory and file permissions will nab you every time. Another of *nix's greatest strengths that can also be a royal PITA.

    ...and yeah, that default /var/web/html directory is VERY misleading in what it does and what it's for. .htaccess is ignored in it, PHP won't run from subdirectories, and there are a host of other oddball limitations. SOME installations will even rewrite the index.html back to the Apache default if you change it. :/

    Made all the more confusing by things like XAMPP/WAMP installations that lack those limitations/restrictions even though they use Apache.

    Certainly doesn't help that like most FLOSS / *nix software -- no matter how powerful or useful it is -- it is ridiculously and agonizingly poorly documented. But then I got spoiled in the late '80's and early '90's by software from companies like Borland that came with 300 to 500 page books.

    Good to hear you got it sorted.
    Last edited by deathshadow; Feb 7th, 2019 at 11:00 AM.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •