Tim! You are so correct on the "typo" /var/www/social/html Someone else had mentioned this I kept looking over -- completely missing it! two sets of eyeballs. thanks I'll test what you sent. It's a start to help trying to figure out what might be user issues from my side. 'ppreciate it all! On Fri, Jun 12, 2020 at 11:40 AM Tim via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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 _______________________________________________ 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
