Trying to get Apache working
Hi LRL! Given your problem description we will discuss what we would attempt to fix the issue. I hope it helps!
Conventions :)
Please note we'll refer to apache2 as a process, service or daemon interchangeably. The meaning we personally confer to these is:
- Process: A running program/piece of code plus its data. Anything running in a computer from a browser to the kernel is a process.
- Service: A process that offers some kind of facility like printer spoolers or a database.
- Daemon: A process that's not designed to interact with the user directly, be it through a terminal, a graphical user interface (GUI)...
Then apache is a process like any other that offers a HTTP server as a service and that behaves like a daemon as we configure it through *.conf files but don't interact with it while it's running in the common way. Some people will not agree with our view but this is what we'll use throughout the following discussion.
Now, let's get down to business!
Don't forget the sockets!
First check that the HTTP daemon is indeed listening. As you could run ip addr with no problems it means you have the iproute2 suite installed. This suite is just a bunch of tools that let you retrieve information about your network stack as well as configure it. You can read more on it here as well as see how they relate to the old net-tools counterparts. One of iproute2's bundled tools is ss which will let you inspect socket statistics. You can consult the manpage with man ss but long story short you need to run ss -lt. This invocation is leveraging the following options:
-l: List listening sockets only. This will get rid of a ton of sockets your system keeps open for a myriad of tasks.-t: List TCP ports only. As seen at the end of section 1.4 on the HTTP/1.1 RFC this application layer protocol runs on the TCP transport protocol. Hence, we can just get rid of sockets relying on different underlying protocols and make our output even smaller.
On a system we have just installed apache2 onto, the output for the above command was:
foo@coruscant~$ ss -lt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:*
LISTEN 0 5 127.0.0.1:ipp 0.0.0.0:*
LISTEN 0 511 *:http *:*
LISTEN 0 5 [::1]:ipp [::]:*
As the socket exists on our machine we are concerned with the Local Address:Port column which lists the VM's listening sockets. You'll see that the third row contains the *:http value. This is just showing that our socket is listening on all network interfaces attached to the machine (we could be running a server with 2 NICs (Network Interface Cards) for instance) and that it's binded to port 80 the default for HTTP as you could see in the RFC I linked above. Just out of curiosity you could try running ss -ltn to prevent ss from assigning special names to well known ports. You would see *:80 instead of *:http in the value we discussed. Anyway, we can see that the HTTP socket is up and running and that our machine will accept traffic sent to port 80. If your output didn't show this port open consider restoring Apache with sudo systemctl restart apache2 as this is a condition for the web server to serve clients.
Just for the sake of completeness you could also run nmap against your machine. Nmap is a network scanner that can give a lot of information about a host. You can read through its manpage as it's a rather powerful tool but you can just run nmap -A -p 80 localhost from within the VM to scan the HTTP port. The scan results will let you know if the port is open or not. The -A enables version discovery but slows the process so you might as well try to run nmap -p 80 localhost and you'll also know whether the port is open or not. As you might have guessed, the -p 80 option limits the scan to the HTTP port. Note that if you didn't have nmap installed you'll need to run sudo apt install nmap to get it. It's also a good idea to run sudo apt update before installing so that you get the latest version. Even though this second alternative is feasible it might be overkill for the problem at hand. We thought it would be nice to mention it nonetheless :). We're attaching my VM's output so that you know what to expect:
foo@coruscant~$ nap -A -p 80 localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2020-11-09 11:46 GMT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000072s latency).
Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.43 seconds
Is apache configured correctly?
Now that we know the HTTP port is working okay let's take a look at apache's configuration file. As with other services, apache's config lives under /etc. You just need to navigate to /etc/apache2 and inspect the various text files of interest. In our case we want to check whether the default site is enabled. To do that we just need to run cat /etc/apache2/sites-enabled/000-default.conf. This should output something like the following:
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>
vim: syntax=apache ts=4 sw=4 sts=4 sr noet
The line we are the most interested in is <VirtualHost *:80> which tells us we have indeed configured a server on port 80 and listening on all interfaces. What's more, the DocumentRoot /var/www/html line states that this is the directory we'll look through to serve webpages. Just if you are curious you can run cat /var/www/html/index.html. That index.html is the site apache is serving when we connect to it!
Should the /etc/apache2/sites-enabled/000-default.conf file not exist you need to run a2ensite 000-default.conf to enable the site. Note this last command might need sudo prepended to it depending on how you've configured your server's permissions. The a2ensite script will just create a symbolic link (like the ones we make with ln -s within /etc/apache2/sites-enabled to a file in /etc/apache2/sites-available. That way you can have multiple "sites" defined and only use a subset of them at any given time. If you run file /etc/apache2/sites-enabled/000-default.conf you'll indeed see it's just a symlink :P.
Then it must be the network configuration...
Now we are sure of 3 things:
apache2 is running.- It's listening on port 80.
- The default site is enabled.
Please bear in mind all the networking commands we'll be including are to be run on the VM, not on the host, unless we explicitly state we want to run a command on the host.
This means the error is most likely in how the network between your host and the VM is configured. First of all, you cannot use the NAT mode when configuring the VM's networking. Due to the very nature of NAT you won't be able to reach your server unless you forward a port on it to the server manually. We have never done it with VirtualBox and don't even know if it's feasible so we'll just steer clear of it.
I personally recommend you configure it with a bridged adapter. This will make your VM join whatever LAN your host PC is connected to as if it were a totally independent machine from the network topology point of view. It's as if your host and VM were connected by a bridge which is a layer 2 device that's not taken into account by the IP protocol which lives in the 3rd layer. You can see that if you configure your VM in this way its gateway is the same as your host's. You can check so by running ip route | head -n 1 | awk '{print $3}' in both and seeing you get the same IP address which is presumably your access router's IP in your LAN. The previous command just prints the route table with ip route, gets the first line which is the default route with head -n 1 and prints the third word which is the gateway's address with awk '{print $3}'. The pipe character | will redirect the output of the command on its left to the input of the command on its right so that we can use several in a coordinated manner. This is a "UNIXy" way of doing things in case you want to do some computer science archaeology :P.
If both PCs do have the same gateway you should be able to ping one from the other and vice versa. To do that you need to know your VM's IP within the LAN. You can get it by running ip addr and checking the assigned IP to your NIC. As you said the interface name enp0s3 showed up you should then see an IPv4 address next to it. Let's say that address is X.X.X.X, then, if you run ping X.X.X.X from your host you should get a reply. If for whatever reason there's no IP associated with the enp0s3 interface just look for an IP within your subnet associated to another one: I cannot guess how you have set up your server...
If you don't get a reply then you'll need to go through the VMs network configuration and make sure everything is set up correctly. If you have internet connectivity from the VM then an interface other than loopback needs to have an assigned IP address so that should be the one you use. If after the above it still doesn't work please attach the complete output of ip addr on the server as well as the complete network configuration for your VM via screenshot for example.
If on the other hand the ping was successful you just need to open a browser in your host machine and type http://X.X.X.X and you should see apache's welcome page :P. I have only tried this from within a VM I had running on my machine so you might run into some "this page is not secure" issues due to HTTP depending on how you specify the URL in the browser. If you explicitly include http in the URL you should not have any problems though. Nonetheless, these issues are beyond the scope of the question so if they take place consider opening a new one.
Best of luck!
I hope the answer was helpful! If there's anything unclear or if you find any type/mistake please feel free to edit the answer or get back to me to help you further. I would nevertheless like to ask you to please provide ip addr's output if you need any further assistance as I'm still in the dark as to what your server's network setup is.
I'm sure you'll get this fixed in no time! :P
