Topic on Project:Support desk

It seems there are many ways to install Mediawiki. I've looked through the "installation guide", "software bundles", and the "intranet" page, and probably others. I'm surprised how many ways there are. The "Intranet" page seems like it might be what I'm looking for since I want to install at my work. Also it has a visual editor and other built in things. Really I don't know which way I should install though. Is there a comparison of the different ways?

There hasn't been a lot of effort to compare different ways. Anything from tarball, to git checkout, to an automated installer like Meza work.

What are your skills and how dirty do you want your hands to get?

Has there been any effort? I'm interested in any opinions to help me decide.

I didn't know what tarball or git checkout meant until I just looked them up and only kinda understand now. That probably gives you an idea of my skill level. I don't mind getting my hands dirty and learning things but I also want to be smart about how I spend my time and a lot of the install methods seem like a lot of work.

The Meza page seems really good at first but then the thing it says is the "easiest way" is a long page with lots of commands.

Don't know much about Meza, but among Git and Tarball, in the long run Git is definitely the more efficient option, especially when the time comes to upgrade MediaWiki.

With Git, generally speaking, an admin needs to only learn and save the commands the first time around and then pretty much copy-paste them for any future updates.

Git may be good for point releases, but I disagree about using git for major upgrades. Upgrades should be done on a new and empty directory. Upgrading a live wiki from git can render the wiki with errors, since everything isn't updated at once (MediaWiki, extensions, skins...), configuration settings may need adjustments, etc. Use git for upgrades only if you plan to put the wiki completely offline during the upgrade.

I suppose you're right.

One setup I've come across, is to make a duplicate directory and database of the live Wiki; test the upgrade there; solve all extension/skin/configuration errors. Then lock the live Wiki and update it in one go, with everything taking 2-8 minutes. I suppose such a setup is only workable for small, low-edit Wikis.

Although, upgrading mixture of release and master branches of extensions would be more work without Git. Unstable extensions often require multiple branches to be tested.

Yes, the safest method is what you describe, either with git or tarball, and once it's OK, make the public webserver folder point to the new directory.

Do you have a page that explains how to do the installs your talking about?

The main difference is in how MediaWiki core and extensions are downloaded to your server, either through a packaged Tarball or through Git. The rest of the installation, upgrading and debugging is pretty much the same.

I couldn't live without Meza. I've found that for any truly serious mediawiki deployment, you want to have at least a local development environment plus a production environment. Git is a necessary pre-requisite for managing volumes of vendor source code and third-party extensions, configurations and custom local environment integrations or private development. To Ciencia Al Poder's argument, you can use git the same way that you would drop a new tarball into your environment: do clean checkouts and switch your mediawiki directory. But with Meza, you don't have to do this at all. Using the Opcache.validate_timestamps setting, we have all PHP code loaded into cache where the server doesn't check for new versions of the source until we tell it to -- which is /after/ we deploy a whole updated version of mediawiki plus extensions. So, without taking the server offline, we can still upgrade all PHP code atomicly. But like I said upfront, you can do all this in your local development or staging environment prior to ever doing it on your production environment. Meza does so much more than install mediawiki; it allows you to create and manage "identical" environments that can be reproduced anywhere at any time. Meza is complex. Meza is also indispensable for creating those reproducible environments. To craft an installation 'by hand' and then maintain control over both the application itself; and the whole environment is really a serious undertaking requiring a _lot_ of knowledge. Meza doesn't relieve you of the need for expertise, but does gives you the benefit of all the expertise of those using it and testing it in their deploys. Finally, Meza provides a "standardized" way of deploying MediaWiki so instead of "no two installations are the same" you get the benefit of all deployments following the same tested model -- which is why I use it as the basis for hosting MediaWiki for clients.

I'd like to echo Greg's comment above. I'm running Meza 1.30 since April of 2018 and am now (today) actively working to upgrade meza to the official stable 1.32 release, but I'm new to git and not knowledgeable enough in linux to confidently know how and where to get the 'right' tarball to download and what it will and won't overwrite.. So I am proceeding cautiously by making sure my server is imaged and ready to roll-back if needed and also trying to read everything I can here to understand what I'm about to do. I have custom haproxy and apache configurations that I can not let meza overwrite .. I'll try to create a page here on mediawiki/meza that captures my notes on the upgrade effort for my environment.

Rich,

Meza will want to manage your HAproxy and Apache configurations. The trick is to figure out what customizations you have for those systems and then work them into Meza roles so that a new deploy does exactly what you want it to do. For example, Meza binds port 443 to a self-signed certificate called meza.pem. I've been working on a role to integrate LetsEncrypt into Meza 100%. But, in the meantime, what I do with every deploy is simply add some commands so that my deploy uses my official SSL certificate instead. I accomplish this by moving meza.pem out of the way and creating a symbolic link called 'meza.pem' to my official certificate and restart HAproxy.

meza deploy production --extra-vars 'wiki_id=en' --skip-tags gluster,backup,update.php && cd /etc/haproxy/certs && mv meza.pem meza.pem.backup && ln -s fswiki.familysearch.org.pem meza.pem && systemctl reload haproxy && cd /opt/meza

It's a bit of a hack, but works. Meza instructs HAproxy to bind to meza.pem; but meza.pem is (a symbolic link to) an official certificate for my domain.

Hi Greg, thanks. In my environment, my apache and haproxy config files are monitored by my application security division and are understood to be "verified and locked down". Any changes I (or meza) make will be viewed as a security incident and gain unwanted attention from the application security response team.. This is why I feel meza should have a simple config switch capable of making it a "mediawiki application only" software. For users who are allowed to "own" their underlying LAMP stack, MEZA is a godsend.. but in my world, that comprehensive control that meza takes of both the LAMP stack and the MW app is too much.

My solution has been to ensure that the following lines are commented in my meza src folder:

My goal is to work you you guys to get a pull request submitted to perform the bypass of these httpd.conf and hapaxy.cfg as a function of a switch in /opt/meza/config/core/defaults.yml .. but I have yet to use git for anything so I need to learn how to do even the most basic tasks in github.. as yet I have not found the time to self-learn and I can't find anyone to give me a crash course. So my progress on this is slow.

Proz2,

Have you attempted installing yet, or are you still looking for a method? You mentioned you want this for work. Do you know what type of server you would use? Would it be Windows, Linux, or something else?

If you haven't tried installing yet, I'd recommend trying it out on your own computer first. I read through some of the pages you made reference to, and I agree they are a bit overwhelming. If your own computer is a Mac, I'd look at Manual:Running MediaWiki on Mac OS X. If you're on Windows I'd still essentially follow those same directions, but install XAMPP instead of MAMP. There are Windows directions but they're a bit wordy if you're just looking to get started.

Installing this way (using the web installer) is probably the most common. There may be many different installation manuals, but many of them are variations of this. I've used this method many times and I think it works well. However, personally I think Meza makes it easier to get going, and certainly makes it easier to install more complicated things like Visual Editor and a better search system. I encourage you to try the web installer, Meza, and others.

Full disclosure: I'm one of the original authors of Meza. It's not something that makes me any money, though. It's just something that makes it easier to manage my installs of MediaWiki.