Problem with using Virtual Hosts (solved)

[DragonsEye]

Hi, I am new to the forums here, but have been using SolydX for about three years.

I am trying to set up a good web-development system on one of my home computers. I do not have home internet access. I almost exclusively use XAMPP for Linux as my server "stack", especially since it can all be installed from one file (Bitnami installers ROCK! :rock: ).

I want to try to simulate a server environment somewhat similar to a web-hosting server (which means multiple domains, website, etc. hosted on one machine).

I am very well versed in the Apache config files and howto's of them. I am also very familiar with the role of the local "hosts." file, and its role in being the first step in resolving domain names to IP address before any of the online DNS's are queried.

My problem:

It seems that I can not access any of the created virtual domains on my machine, but instead see the web browser try to search for it online (which results in a "Not Found" error). I have concluded, by process of elimination, that it is not from the browser (FireFox), not from XAMPP (this works well on other distros without headache). This problem of not honoring my hosts file, and not locally resolving the virtual domains to their assigned IP addresses on my machine is common on SolydX versions 8 and 9. Most other other distros I have played with, seem to not have this problem (even with exactly the SAME settings in the hosts file - and - in Apache's config files).

If I can not get virtual domains to work, and be addressable with SolydX, this reduces the usability of the operating system for my web-design projects, AND learning about how web-servers work. (Projects like these, are how I teach myself these technical skills.)

My sample hosts file:

Code: Select all

#<ip-address>	<hostname.domain.org>	<hostname>
#127.0.0.1	localhost.localdomain.org	localhost
127.0.0.1	localhost
127.0.1.1	web-host1
127.0.2.1	web-host2

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

and an example Apache "vhosts.conf" file:

Code: Select all

# Virtual Hosts
#
# Required modules: mod_log_config

# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at 
# <URL:http://httpd.apache.org/docs/2.4/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot "/opt/lampp/htdocs"
    ServerName localhost
    ServerAlias localhost.localdomain.org
    ErrorLog "logs/error.log"
    CustomLog "logs/access.log" common
</VirtualHost>

<VirtualHost 127.0.1.1>
    ServerAdmin webmaster@web-host1
    DocumentRoot "/home/web-host1/htdocs"
    ServerName web-host1
    ServerAlias web-host1.localdomain.org
    ErrorLog "/home/web-host1/logs/error.log"
    CustomLog "/home/web-host1/logs/access.log" common
</VirtualHost>

<VirtualHost 127.0.2.1>
    ServerAdmin webmaster@web-host2
    DocumentRoot "/home/web-host2/htdocs"
    ServerName web-host2
    ServerAlias web-host2.localdomain.org
    ErrorLog "/home/web-host2/logs/error.log"
    CustomLog "/home/web-host2/logs/access.log" common
</VirtualHost>

* * *

Though the IP addresses resolve to the pretended domain names (as evidenced by looking at the PHPINFO results when accessing these addresses by IP address), the domain names will simply not resolve to the IP addresses, and are not accessible.

I do not want to be reliant on accessing the other "virtual sites" by having to type in their IP addresses in the browser's address bar, instead of their assigned virtual domain names.

Again,

I have found this only to be a problem with SolydX, and not any of the other Debian Linux distros I have played with.

I have also not found anything online (via Google or otherwise) that addresses this problem with SolydX? ? ?

My question:

What system setting(s)/configuration(s) do I need to change, in order to get virtual domain names to work as it should, like it normally does on other distros (operating systems, and such)?

[ilu]

A common problem with lamp on Solydxk results from it being a desktop system, so it's optimized for desktop usage. The first thing that comes to mind is that apache doesn't like the way Solydx handles /tmp and /var by putting them into tmpfs. Even if you don't think that this can cause your problem you should copy them and change fstab to put them onto a disk to get a standard setup. I don't think any server config will work with that tmpfs construction. Please check this and report back.

[Arjen Balfoort]

I found this tutorial helpful: https://askubuntu.com/questions/746537/ ... untu-14-04

[DragonsEye]

I found this tutorial helpful: https://askubuntu.com/questions/746537/ ... untu-14-04

Thank you for the suggestion but,

I had already checked that one out, and found that it did not resolve my issue. On other Linux distros - this seems to work just fine, just not on SolydX.

[DragonsEye]

A common problem with lamp on Solydxk results from it being a desktop system, so it's optimized for desktop usage. The first thing that comes to mind is that apache doesn't like the way Solydx handles /tmp and /var by putting them into tmpfs. Even if you don't think that this can cause your problem you should copy them and change fstab to put them onto a disk to get a standard setup. I don't think any server config will work with that tmpfs construction. Please check this and report back.

XAMPP seems to have very little problem with the /tmp and /var folders because it it has its own (/opt/lampp/tmp and /opt/lampp/var) to work with. As with any temporary(ram-based) filesystem, any contents that need to be used for the next session startup - are saved to disk on shutdown or restart anyway.

The issue I am experiencing has more to do with one or more of the "customized" settings that are applied during post-installation; most llikely - within FireFox. Being that this OS installation is on a desktop without access to the internet - installing another browser to test this is not a very workable option.

As to the server side of things,

I do not believe it is too much a concern of the server subsystem as it is more likely between the OS and the browser (namely, one or more settings need to be changed). What is happening is that the hosts file settings are being ignored, and DNS-resolution is being done (attempted) entirely through a non-existent network (the lack of internet connection).

What I am looking to do,

Is restore the ability of DNS-resolution to where the hosts file is checked first (as is usually the default on most networking-capable operating systems) before attempting to look up the DNS's online. In many LAN configurations where each machine has and is addressed by its own hostname, the hosts file is where internal DNS-resolution takes place (if not done in the networking router instead).

So,

My next course of action then, is to compare the browser settings from my development machine's browser to those on a different machine that is running a different default install of FireFox. This will probably take about a day (with my busy schedule, anyway).

By all rights, any setting in the hosts file that properly resolves to an IP address - should work regardless whether on a basic desktop, notebook, or networked server. This is what networking-capable operating systems from the old UNIX and MULTIX operating systems did then. Even the NT-based Windows OS versions have this capability built in.

[ilu]

Disclaimer: I have never tried anything like you described and I never use apache but nginx. Anyway, some ideas:

Did you do step 1 of https://ourcodeworld.com/articles/read/ ... -in-ubuntu ? (Even if it's Ubuntu it should be similar).

So if you think it's a browser problem:
1. First thing would be to start the browser in safe mode, go to about:support to do that and see what happens.
2. Create a new profile, to be sure delete everything in it, start Firefox with -p and let it recreate its standard config. See what happens.
These two steps should exclude any SolydX specific browser configs.

I entered "Firefox ignoring host file" into startpage.com and got this as first result: https://support.mozilla.org/en-US/questions/1011327 - so obviously you are not alone and it doesn't seem to be Solydxk specific problem - the guy starting that thread and several others weren't using Linux at all. He has a theory why the browsers keyword search function (default on, try switching it off) might stop the browser from ever receiving anything from the hosts file - although that should not happen if /etc/nsswitch.conf is configured correctly. Mine has

Code: Select all

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files  
netgroup:       nis 

The hosts line should be correct (hosts file first). I'm not sure about the other entries and I wonder about db ... you could change them to files before db for debugging purposes but you'll have to check the corresponding files in /etc.

I haven't read through all the stuff that came up in the search but I saw one post that said that you always need to specify IP4 and IP6 addresses for every location, whether the host works with IP6 or not. And network.dns.disableIPv6 should be set to default false in about:config (which it might be - I don't know the SolydXK default settings since I use a rather large user.js.)

Next idea: What is the result of "getent hosts <web-host1>" ? And if you don't have another browser try wget. Do getent and wget work as expected or not?
Are you behind a proxy? In that case you'll have to re-check that conf in Firefox. Entries need to match the hosts file.

[kurotsugi]

please CMIIW, the way your hosts file was made, if you type "web-host1" on the browser, it can't access the defined ip address since you only specified ipv4 address. the solution would be either disable ipv6 or add ipv6 address in your hosts file.

[DragonsEye]

please CMIIW, the way your hosts file was made, if you type "web-host1" on the browser, it can't access the defined ip address since you only specified ipv4 address. the solution would be either disable ipv6 or add ipv6 address in your hosts file.

As you can see from the provided files,

I only use IPv4 addresses anyway. So, disabling IPv6 address settings - OR - entering IPv6 addresses into the hosts file should make absolutely no difference.

Disclaimer: I have never tried anything like you described and I never use apache but nginx. Anyway, some ideas:

Did you do step 1 of https://ourcodeworld.com/articles/read/ ... -in-ubuntu ? (Even if it's Ubuntu it should be similar).

So if you think it's a browser problem:
1. First thing would be to start the browser in safe mode, go to about:support to do that and see what happens.
2. Create a new profile, to be sure delete everything in it, start Firefox with -p and let it recreate its standard config. See what happens.
These two steps should exclude any SolydX specific browser configs.

Actually:

After spending about two sleepless nights searching and comparing browser settings (from two different running Linux packages), and scanning line-by-line from the "about:config" page,

Here is what I found, that was keeping me from getting virtual domains to work:

network.dns.disableIPv6 - "user set" to "true", -- So I changed it to "false" (as is the usual default setting) - and - VOILA! I finally got virtual domains to work properly on my machine! -

So, one may wonder WHY this setting, named as it is, would also create problems with local virtual domain addressing using IPv4 address ? ? ?

I guess my question about this, would be best addressed to the folks at Mozilla, but this seems to me to be an unintended "bug" - or - perhaps misnomer of a setting? -

I did consider possibilities about the other browser setting (also found in -about:config- page):

browser.fixup.alternate.enabled - defaulted to: "true". I think this would not be as much a problem, but setting it to "false" did not cause any harm anyway.

So,

For the time being, I have finally set up my simulated web-hosting server at home - and have virtual domains working perfectly!

So thanks to everyone who at least tried to help. That's what makes forums, like this one, VERY good to have available.

As far as the newer version of SolydX,

I think it really :ROCKS!:

* * * NOTE: Can mark this as resolved (for the time being).

[ilu]

And network.dns.disableIPv6 should be set to default false in about:config (which it might be - I don't know the SolydXK default settings since I use a rather large user.js.)

Quoting myself here to show off that I KNEW it

Glad you got it working.

[DragonsEye]

I took a good look at the issue posted on Mozilla's "help-board": https://support.mozilla.org/en-US/questions/1011327

Then I came to realize something,

Because most of the versions of FireFox (and Chrome) were also ported to mobile devices, the URL address bar doubles as a search blank. The commenter on the Mozilla post, apparently, did not take this into account, nor of the fact that the desktop versions of these browsers share the "feature" (as opposed to "bug"). (Most likely, because they are built from a common code-base.)

Therefore,

As to the search-suggestions popping up when one types a single word (virtual) domain name into the address field, the browser thinks you are wanting to search, using it as a "keyword".

The solution to this "problem" was really quite simple: Append a "/" to the end of the virtual domain name, and the browser will try to access it as an actual URL! This also resolves the problem of the browser's "fixup" settings too, as the "/" at the very end - makes the browser treat your address bar input as a possible URL.

Again, hardly an actual "bug", but more a feature that some of us did not quite fully understand.

The "IPv6"-disable setting, though, was still the heart of the original problem.

So,

It seems I did a little more learning as time went on, AND while doing some serious "digging".

So the only setting that needed to be changed, was the setting that "disables IPv6" resolution (which should have ONLY applied to IPv6 Addresses, and NOT also IPv4 - apparently").