Error 500, this seems to be a common one

[ShadowWizard1]

Well, users can register, activate there account, but as soon as they do, they get an error 500. The account activates and it ads them to opensim, however they are unable to navigate the web page any more. Whats with this?

[Usalabs]

Server error 500 on Linux means your using the wrong PHP version, I have PHP version 5.6,7,7.1,7.2,7.3,7.4,7.5,8.0 and 8.1 and I can switch them using a bash script I wrote, I normally use PHP v7.3, but when I try to run Mwi with that, I get internal server error 500, but when I run it with PHP v5.6 everything works.

The ONLY problem I saw was that there's no further instructions on how to set up the home page, and how do I add modules to the home page, and also the creation of links causes a server error 500, so unless we know precisely what environment Mwi was developed and working on, it won't work at all.

[GwynethLlewelyn]

Well, I'd say that the main problem is that Mwi is 'abandonware'. I did try to get it going with more recent versions of PHP, but to no avail. You see, the core application uses Laravel as the framework. It's so old that the version used is not even mentioned on Laravel's homepage; support for it ceased over a decade ago, since it was designed to work under PHP... 4 (!). Granted, with a little patching, you could get it running — with some oddities — up to 5.6, I guess; I haven't tested it under 5.6 for a long, long, long time...

It's a pity, because it was such a useful tool for smaller grids, even with those oddities (the most annoying one being the map, which would sometimes work, and sometimes not — it was tough to debug!).

Due to the lack of ongoing support, at the end of the day, I decided to give up on more tinkering, and designed my own tool from scratch — using the Go programming language :) To avoid being accused of spamming this thread, I'm not giving any links nor pointers, but it's easy enough to find it from my profile... it's not a 'clone' of Mwi (I also drew some inspiration from XOOPS, or whatever it is called these days, which is undergoing a big code refactoring, last time I checked), and it does not include all the features that Mwi had (namely, the messaging/notification system is still a WIP), but, alas, it suited my own purposes... the code is neither idiomatic nor exceptionally clean (I'm not a professional programmer), but at least it doesn't depend on any obscure, outdated frameworks...

[GwynethLlewelyn]

... actually, I just checked, Mwi is supposed to support PHP only up to 5.3.2. Anything after that will fail, one way or another :-)

[Usalabs]

... actually, I just checked, Mwi is supposed to support PHP only up to 5.3.2. Anything after that will fail, one way or another :-)

Yes, I'm lucky in that my server has all the previous and current PHP versions from 5.3 to 8.1 and I created a menu driven bash script to change the MOD and CLI versions of PHP.

After examining 'go' it's more complicated than just installing Apache and PHP, at least with Apache and PHP I can use webmin to administer the web server.

Anyway, I finally got Mwi to sort of run but I still get error 500 when creating content and navigation links, so I just use the splash screen and using PHP 5.6, until a better system comes along that can be used on apache webservers.

[GwynethLlewelyn]

Anyway, I finally got Mwi to sort of run but I still get error 500 when creating content and navigation links, so I just use the splash screen and using PHP 5.6, until a better system comes along that can be used on apache webservers.

I guess that what you mean is 'a system written in PHP' — since you can always use Apache as a reverse proxy to whatever backend tool is running.

Official guide: https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html

Naturally enough, you need to have mod_proxy active and enabled in Apache; this should be easy to accomplish using whatever package manager you have on your system.

If not, you need to compile it youself. Here's a guide from Digital Ocean: https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension

Essentially, what you need is to add a special configuration for your VirtualHost. Suppose that the backend application you've got is running on the same machine as Apache, on port 8080. All you need to do is something like this (adjusting for your own configuration):

   <VirtualHost *:*>
        ProxyPreserveHost On

        # Servers to proxy the connection, or;
        # List of application servers:
        # Usage:
        # ProxyPass / http://[IP Addr.]:[port]/
        # ProxyPassReverse / http://[IP Addr.]:[port]/
        # Example: 
        ProxyPass / http://0.0.0.0:8080/
        ProxyPassReverse / http://0.0.0.0:8080/

        ServerName localhost
    </VirtualHost>

The links I posted above show many extra configurations, especially those related to using Apache not only as a reverse proxy, but also as a load balancer as well.

In fact, if you use Apache with PHP-FPM (as opposed to using the built-in mod_php), Apache will very likely be already configured like that!

There are many advantages to this approach:

• You encapsulate whatever application you're running on your system, making sure it is never accessible to your front-end users on the Internet — the application will run tied to localhost only and not exposed to the public Internet
• You can manage everything from webadmin or any other tool you've already got for managing Apache virtual hosts: it's just another virtual host, after all
• Whatever security rules you have already enforced in Apache will apply to the application as well; after all, your (external) users will only contact Apache, nothing else, and every communication to the application will be filtered by Apache's own rules first
• An additional advantage is that Apache can also be run as a cache for static resources — in other words, there is no need for the application to be contacted in order to retrieve, say, a map tile, or a snapshot taken in SL, or CSS/JS files used by the application; you can store all of those on a separate folder and let Apache just serve them directly. This will mean fewer communications between Apache and the application server, and less waiting time for static resources — Apache will handle them all
• Also, if you run your own caching system or reverse proxy in front of Apache — say, Varnish, or Squid, or nginx, or even an external system such as the one provided for free by Cloudflare — you do not need to add any special rules for the application itself. Since it's been accessed as an ordinary Apache web host, it will just fit in whatever extra layer you've got in front of Apache; all those tools don't 'know' about the back-end application, for them it's just Apache they're contacting
• Whatever improvements you add to Apache itself — such as, say, Google's PageSpeed — will also work transparently with whatever backend application server you've got. In other words, it's not just static content (or, well, results from calling a PHP application...) that benefits from whatever improvements you add to Apache: anything that is reverse-proxied by Apache gets those benefits as well, and you don't ever need to change a single configuration line of those back-end applications
• Therefore, from the perspective of the system administrator, such a back-end application is managed just like every other virtual host; you can add it to your system with whatever configuration tool you prefer, create a separate environment just for the application (i.e. putting it in its own directory under its own special user — just like every other virtual host), and, if you have tools for that, limit its disk quota, or bandwidth, or whatever you do to the other virtual hosts, using the same exact tools you use for them

Or, in other words: you don't really need to 'be afraid' of a 'complicated' approach to manage a stand-alone application; just encapsulate it under Apache and manage it as you do all the other virtual hosts!

I do that for all components in my system that require being exposed to the 'outside world' (with the sole exception of OpenSim itself — that's trickier to do, since OpenSim uses lots of UDP connections, which are very hard to reverse-proxy, and, in any case, it's certainly not possible to do that under Apache anyway (Apache is a web server, meaning it can only do its magic to web applications that understand the HTTP(S) protocol(s)).

FYI, in my case — a bare metal server running Ubuntu Linux — I don't use Apache, it's too bloated for my purposes; I rather prefer using nginx, which is orders of magnitude faster (for the kind of things I need it to do, of course — others take the same amount of time) with a tiny memory footprint. Additionally, I use Google's PageSpeed modules and Cloudflare on top of everything. I do have several stand-alone applications running all the time (some in PHP, some in Go, some in C, some in whatever programming language they were written — I might not even know), but all of them are shielded behind all these layers, never exposing them to the public-at-large. Everything I have there is managed centrally using ISPConfig3 — webmin and the other tools are simply too limited for the kind of things I need to configure all the time (aye, I used all of those in the past, but finally settled with the free and open source ISPConfig3, which does 99% of all the chores I need to do, well beyond just managing directories, users, and virtual hosts).

Then again, that's just me :-)

On the other hand, you can still take a look at the XOOPS module for OpenSim :) — or, alternatively, grab the list of current OpenSim backend applications — all of which were written in PHP, and many of them being listed as still active.