Re: waaaay off topic -- apache/vhost

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2020-06-12 at 09:54 -0400, bruce wrote:
> The TLDR; -- Trying to set up the vhost block to be able to access a
> test site built on an app called "open social" from/basedon Drupal.
> The app is https://github.com/goalgorilla/open_social

Okay, I don't do drupal (or other content management package), but I do
use Apache and virtual hosting for several different websites, hosting
flat HTML files.  Though I saw a note that Apache will be changing how
they configure virtual hosting some time soon (just to throw a spanner
in the works).

> I have a "test" vhost that kind of works, -- uses
> Alias/DirectoryBlock/DocumentRoot, but it kept generating redirect
> errs. Someone on the OpenSocial slack channel said to get rid of that
> and .. But didn't say how to implement a correct config file.
> 
> Trial/Error sometimes not the most efficient approach.
> 
> The test url that currently generates a 403 is:
>     http://161.35.180.212/social/

I get a forbidden 403, too.

> I've managed to generate the required files via Composer, and the
> files are stored in the following dir:
> 
> /www/var/social

Is that filepath correct?  If you've made a special www directory in
the root of the directory tree, SELinux is going to bite you for trying
to serve files from a non-standard filepath.  I'll presume you really
meant /var/www/social and all your content is within that filepath.

e.g. /var/www/social/homepage.html could be your homepage file.

For that kind of thing, I have individual configuration files per site
in the /etc/httpd/conf.d/ directory.  I'll try to mock one up for you

Create a file: /etc/httpd/conf.d/social.conf

<VirtualHost *:80>
        ServerName         www.social.example.com   
        ServerAlias        social.example.com
        UseCanonicalName   On
        ServerAdmin        badouglas@xxxxxxxxx
        DocumentRoot       /var/www/social
        DirectoryIndex     homepage.html default.html index.html index.php
        Options            Indexes FollowSymLinks MultiViews Includes
        ErrorLog           logs/social-error_log
        CustomLog          logs/socail-access_log combined
</VirtualHost

The ServerName will use your actual domain name.

The ServerAlias can list alternatives (e.g. making a site work with or
without the www prefix, or even for completely different hostnames,
such as your local hostname when testing within your LAN).  You list
all alternative names separated by blank spaces.

UseCanonicalName tells the server to use your domain name, correcting
how someone may have alternatively accessed the site (e.g. via IP).

ServerAdmin is just a contact address that the server may display on
some error pages.  It's presumed to be an email, and many applications
may only accept that.  But it's possible to use a URL (e.g. a contact
details page).

DocumentRoot is where the files are served from (NB what I asked before
about your unusual filepath).

DirectoryIndex is the default file the server will read if someone
requests an address of a directory, rather than a file.

e.g. when they browse to www.example.com/something/
     rather than www.example.com/something/page.html

You can list more than one filename for it to look for.  While
index.html is the typical default value, not all default web pages are
actually an index, nor a homepage (which is really the landing page for
the whole site), so you customise it to suit yourself.  And if you're
using scripted languages like PHP, that needs to be enabled, too (the
handler for PHP, etc).

Options can be specified to override default webserver options
specified in the main configuration.  You may not need any of these
examples.  Here, Indexes allows the listing of files in directories
that didn't include a default page for DirectoryIndex to find. 
FollowSymLinks allows the webserver to use symlinks pointing to files
outside of your DocumentRoot (though other things may override that). 
MultiViews allows the server to choose different media for the same
file, as best suits the situation (e.g. a page could want to display an
image called "diagram" and in your directory you had diagram.jpg,
diagram.gif, diagram.png files of the same image, it'd pick what it
thought was best).  It can also be used for multi-language pages (you
could have welcome.html.en file  and welcome.html.es and
welcome.html.ru and when someone requested welcome.html they'd get the
page in one of the languages they've configure their browser to
support).  And Includes let pages include content from other files,
when they use SSI code within the HTML.  If put code like this on my
pages  <!--#include virtual="/nav.menu" -->  the webserver renders the
content of that nav.menu file into the page, instead of that bit of
code.  It allows me to write one common navigation menu that all pages
will use, and I can change the navigation menu at any time and not have
to rewrite all the pages with the new links.

ErrorLog and CustomLog say where to save logfiles (above I've used
relative links, to its default logpath, but could be a full filepath),
and there's a code (combined) for the formatting of the data to log.

With a configuration file like that, and a test HTML page in the
Document root (/var/www/social/default.html), you should see that page
when you browse to http://www.social.example.com/ (or whatever actual
domain name you own).

It is dependent on there being a DNS record associating the webserver's
numerical IP address with that domain name, but for internal testing
you can do it within your /etc/hosts file.

Elsewhere, in the main configuration, you'll have a couple of things
that relate to file access permissions.  They'll stop Apache reading
the whole directory tree of your OS.  Allow access to anything within
/var/www (including sub-directories).  And allow further options to a
specific sub-directory, like /var/www/html (the default website for the
Apache installation).

<Directory />
    AllowOverride none
    Require all denied
</Directory>

<Directory "/var/www">
    AllowOverride None
    # Allow open access:
    Require all granted
</Directory>

<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

You may, or may not, need to do so something similar for your own
website directory root.  There are all sorts of ways of making things
more secure for you, and segregating types of content per site.

e.g. /var/www/social/cgi/
     /var/www/social/html/
     /var/www/social/databases/

     /var/www/anothersite/cgi/
     /var/www/anothersite/html/
     /var/www/anothersite/data/

Your CGI scripts going in *your* cgi directory, your webpages that
people request to view inside your html directory, and content that
your data management software uses inside the databases directory where
it can access it, but the general public cannot.

Someone else's website files go elsewhere, where there's no
interaction.

Anybody who tried to connect to your IP, without using your site's
domain name, would connect to Apache's default service, which keeps its
files inside /var/www/html/  Put a test page in there for yourself, so
you can test what's happening while you work this all out.

Of course how you set things up depends on what other software you're
using.  What it needs, what it lets you do, etc...

> within the /www/var/social  (the files for open social are)
> 
> apache apache    109 Jun 11 03:34 .
> apache apache    128 Jun 12 04:16 ..
> apache apache   1858 Jun 11 03:33 composer.json
> apache apache 365863 Jun 11 03:40 composer.lock
> apache apache    602 Jun 11 03:33 .gitignore
> apache apache   4096 Jun 11 03:40 html
> apache apache   1826 Jun 11 03:33 README.md
> apache apache   4096 Jun 11 03:40 vendor

Generally speaking NEVER make webservable files owned by Apache.  As
soon as someone discovers an exploit, they can make your webserver
rewrite the content of any file or directory it owns.  Quite apart from
mucking up your content, they can take over and do hostile things.

Website files and directories should be owned by someone else (e.g. the
author), and made world readable, never world writable.

e.g. directories: rwx---r-x  (owner can do everything, group 
                              permissions ignored, unknown users
                              can read files and enter directories)

     files rw----r-- (owner can do anything, group permissions are
                      usually ignored, unknown users can only read
                      files)

There are some content management packages that advise making things
apache owned, but that may be oversimplified dumb advice, or that
software is simply written by idiots.  The most innocent of websites
will be discovered by people wanting to exploit an open server for
their illegal behaviour.  Drupal, wordpress, et al, are all tasty
morsels for hackers, and often come with masses of security flaws that
need the webmaster to continually update the software to fix them.
 Hence why I don't use them, it's easier for me to write HTML, CSS,
etc., than to learn someone else's content management system.  And keep
up with all the changes they inflict on you over time.

In general, if you use a content management system that lets you re-
author pages, then the files/scripts within your document root are the
pages that people request from your browser, but they incorporate
content that comes from a location outside of the document root.  They
can't directly access that data, your pages/scripts handle it.

Some of that can be aliases, they might request news and there mightn't
be any news file in that directory, but the program recognises the
requested address as an instruction to display the latest news.


-- 
 
uname -rsvp
Linux 3.10.0-1127.10.1.el7.x86_64 #1 SMP Wed Jun 3 14:28:03 UTC 2020 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
 
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux