Hi
> Yes, in a browser, either http://localhost/moodle or
http://x.x.x.x/moodle . (the actual IP address, not 127.0.0.1)
Since the site is meant to be accessed by other computers in the LAN, the latter URL is the right one.
> I can't ping or traceroute the machine or access the moodle site at
http://x.x.x.x/moodle or the test file at
http://x.x.x.x/testpage.html .
Until the first part works, no point in trying the second part.
>>> I have set wwwroot in config.php to the server ip address.
>
> $CFG->wwwroot = '
http://192.168.2.113/moodle';
That's right.
>> DocumentRoot /usr/share/moodle/
>> no brackets, no quote, leading slash in /usr/share/local ?
>
> I think you're right about the leading slash (though the moodle installer put one of those there; I haven't edited the sites-enabled file). I'm suspicious that the quotes don't matter, because doesn't have them, and all the other directories (/usr/lib/cgi-bin , /usr/share/doc) do, but I'll try without.
Don't guess. Read the original docs
http://httpd.apache.org/docs/2.2/mod/core.html#documentroot
> No, no luck with either adding a leading slash or removing the quotes.
Did you restart the Apache service. In most of the Linuxes the start script is in /etc/rcN.d/, where N is the run level. Testing a Debian box
# runlevel
N 2
(so it is in run level 2)
# /etc/rc2.d/S91apache2
Usage: /etc/init.d/apache2 {start|stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean|status}.
In your case a reload is enough:
# /etc/rc2.d/S91apache2 reload
> Could you please explain further about the soft link, what it does, and why I need one?
The equivalent in the Windows world is the "shortcut"
http://en.wikipedia.org/wiki/File_shortcut. That way you avoid duplicating a file, instead create a special file which is just a link. Read about soft and hard links in your favourite Unix book.
> Do the settings in my apache and moodle configuration files really affect whether machines on the same network can see each other (if there isn't a firewall in the way)?
No.
> If so, this seems like very poor planning on someone's part.
Yes, on the part of the person who started the firewall.
>> Remember, security obstructs usability. If you don't know how this firewall works, deactivate it, at least until the basic issues are cleared.
> Firstly, I don't even know enough about this firewall to deactivate it. Secondly, network security is enough of an issue here (and I am aware of enough holes in my security already) that I'm very leery of deactivating it unless there's no other recourse.
You don't even know, whether there is a firewall running but happy about the security "it" gives? What is "it"? Against what "it" protects you?
> Also, if, as I suspect, deactivating the firewall fixes the problem, I'm in an only marginally better position than I am right now:
See Marcus' answer.
> I would be sure (as opposed to almost sure) that the firewall was the problem, but still not know how to fix it in a way that is feasible for the long term.
If the other side is too far for a long jump, some stepping stones might help.
> You have a network manager running in a server? What for? A typical server has a fixed IP address. Or is this machine your "desktop"? Not that it is wrong, but a desktop is different from a server.
> Considering how long it may take before the actual server arrives, it seemed prudent to try to get Moodle up and running before it arrived.
Sure. That is the nice thing about Unixes. I run all sorts of services in my netbook if various occasions. No switching between client and server versions (XP, Vista, Seven ageinst NT, Server 2003, 2008) no harassments on licence codes, no ressource hogging, ...
> (And considering that I've been working on this project for over a week now, I think that was the right decision.) The 'server' that I'm running Moodle on has non-server Ubuntu with all of the packages necessary to behave as a server, and is a machine dedicated to this purpose.
It is the right decision so far. You have made commendable progress in one week. Just two things to keep in mind: 1) Continue to maintain your test "server" like the real server, means don't use a GUI for the server part, then you can just continue in the real server. 2) Don't make the "security" your first concern at this stage. First get everything working, understand how it works, then decide which security you need against what, select the tool(s), learn them then apply.
> This machine has a fixed (local) IP address.
Yet another reason to put security behind, you are in a private LAN!
PS. To know whether there is an IP firewall running,
a) read the boot message (dmesg)
b) check for suspicious scrpts in /etc/rcN.d/
f) get nmap (in Ubuntu: $ sudo apt-get install nmap) and run "nmap localhost", "nmap IP-address" in the server itself. Then move to another linux box in the LAN and run "nmap IP-address" and compare the open ports.