If it’s in Fedora I think it’s OK you may ask (me)

On Fri, 2020-06-12 at 05:00 -0400, bruce wrote: You may as well ask about the problem, then you'll know if people can help. I use virtual hosting on Apache, I've been doing so for years. -- 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.

Am 12.06.2020 um 15:54 schrieb bruce: 2 times a typo for the path? Rethink if it is really required to permit the webserver to be able to modify (write) its own content files. Certainly many file of the application can be protected by being root:root owned and just read by the apache user. That's a Debian style config setup. While the active config is being reflected by /etc/httpd/sites-enabled/foo.conf being the symlink to the active config. See the difference of the DocumentRoot path to what you wrote above. Said that, /var/www/social would be the appropriate path on Fedora and "www/var/" ugly. Look into the log files generated by Apache when accessing your server and application. That will tell you where to search. Alexander

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(a)lists.fedoraproject.org&gt; 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(a)gmail.com > 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(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > 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@lists.fedoraproject.org