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
