WAMP Server / Moodle installation - failing right at start...
March 23, 2020 1:19 AM   Subscribe

I am trying to get a local Moodle installation on my machine for initial testing and self learning. I am stumbling right out of the gates, as I have zero knowledge about the underlying PHP / MySQL / MariaDB setup aspects.

OK, so what I have been able to do, following the instructions online:

WAMP is installed and running. Green with all 3 services running. Apache, PHP, MariaDB, MySQL, all seem to be up and ready.

I was able to follow the instructions online to use MariaDB to set up my initial empty moodle database, from the MariaDB command line. That seemed to work!

Now it is "Moodle Installation" time, and I am trying to do the "online install" which is supposed to happen through a web browser. Here is the problem...

The following error was encountered while trying to retrieve the URL: http://localhost/phpmyadmin/
(and also the same error page trying to go to http://localhost/)

Connection to 127.0.0.1 failed.

The system returned: (111) Connection refused


So, somewhere in all of this config stuff it seems like I need to open / allow my web browser to look at my local machine? What am I missing here?

Sorry, this is really a basic n00b thing, I know. Win10, I have the x64 bit version of WAMP installed. Any help to get Moodle up and running would be super appreciated!
posted by Meatbomb to Computers & Internet (6 answers total)
 
Oh and maybe it is something to do with me using epic browser, as it has built in proxy tools? If this is the problem is there a way to reset so it tries through iexplorer or chrome or whatever?
posted by Meatbomb at 1:24 AM on March 23


Never used a WAMP stack in my life, but if your problem were my problem I'd start by opening a cmd window and using netstat to find out which port(s) the Apache service process was listening on. If it's not listening on port 80 and/or 443, you'll get Connection Refused when attempting to browse to http://localhost or https://localhost respectively unless you also put the port number that it is listening on in the URL, like http://localhost:8080 for example.
posted by flabdablet at 4:18 AM on March 23 [1 favorite]


The Epic browser issue does sound like that would be the problem.
posted by advicepig at 7:08 AM on March 23 [1 favorite]


Thank you advicepig... I kind of solved my own problem, should not have been using epic browser. It is great for websurfing but not for accessing localhost. Tried Chrome and problem was gone.
posted by Meatbomb at 12:00 AM on March 24


Just looked up Epic, and it seems to me that Epic would work for you every bit as well as Chrome if you turn off its inbuilt proxy service when attempting to get to stuff hosted inside your own LAN, which includes localhost. I can't test it easily because I haven't found a Debian-compatible version yet, but I gather there's a control in the address bar for this.

With the proxy service turned on, your Epic browsing session will all be tunnelled through an encrypted connection to one of Epic's servers and exposed to the wider Internet only from there. That means that private IP addresses like 127.x.x.x, 10.x.x.x, 192.168.x.x, 169.254.x.x and a few others, plus hostnames like localhost, will not mean the same thing as they do from your own computer's point of view. In particular, nothing at all that's hosted inside your own LAN will be visible to Epic's gateway server unless you set up network address translation and/or firewall rules on your own router to expose it to the wider Internet, which you probably don't want to do.

With the proxy service turned off, Epic should work just like Chrome does. I'm not able to tell you whether that service setting is per-tab or global, though given that they've put the control in the address bar it might well be per tab, which would be ideal.
posted by flabdablet at 1:46 AM on March 24 [1 favorite]


Yeah, it would be nice if it gave you a virtual "split tunnel" maybe warning you that you are going to something local. I get why they might not, since there are exploits that are trying to embed scripts that hit local ips to try to take over your router/printer/etc, but yeah.
posted by advicepig at 8:44 AM on March 24 [1 favorite]


« Older Replacement home exercise for a swimmer   |   Creating a simple digital archive Newer »

You are not logged in, either login or create an account to post comments