this post was submitted on 16 Jun 2023
18 points (100.0% liked)

Selfhosted

39964 readers
356 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

I currently host a couple small wikis for worldbuilding information, but the hosting provider for that is going down in a few months, so I'm looking for ways to self host what I got.

I've never self hosted with Mediawiki before so this is brand new to me, I've already spent a couple hours messing around with Docker but haven't gotten too far into that. OS is Manjaro/Endeavour Linux between two systems.

Not necessarily looking to host it online immediately to start with, though in the future I'd like to do so when I can get the proper hardware preparations for it, but for now I just want to host it locally to get it set up.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 3 points 1 year ago (1 children)

I'm running MediaWiki for a role playing group in docker. The difficult part was getting everything set up to get certificates from letsencrypt and offering https without leaving docker compose. The great thing about this is that creating a backup or moving servers has become trivial now. As long as you don't expect your users to perform dozens or even hundreds of operations per second, I'd strongly advise sticking with SQLite to make your admin life that much easier. If you want, I'll look up my full stack and post it here once I'm not on mobile any more.

[–] [email protected] 1 points 1 year ago (1 children)

That'd certainly be helpful, if I'm able to get started then I feel like the rest shouldn't be too rough given the resources I'm finding, but starting it is the hard part for me.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

Sure thing.

So there are two parts to all of this:

  1. Getting MediaWiki set up , properly configured and running.
  2. Having it securely accessible from the Internet (if needed), including SSL certificates.

Part 1 is well covered my the MediaWiki release already. You only need to worry about the correct configuration. When you download the current version from the official MediaWiki page, you'll notice that there is already a docker-compose.yml file in there. This gets you most of the way to your destination.

Read the file and set the values of all variables you wish to override in a separate ".env" file in the same folder. It could look something like this:

MW_SCRIPT_PATH=/w
MW_SERVER=https://your-url.com
MW_DOCKER_PORT=80
MEDIAWIKI_USER=Admin
MEDIAWIKI_PASSWORD=some_password
XDEBUG_CONFIG=
XDEBUG_ENABLE=true
XHPROF_ENABLE=true
MW_DOCKER_UID=1000
MW_DOCKER_GID=1000

Now you can just docker-compose up and everything will be set up when visiting your site for the first time, it should hold your hand, guide you through configuration options and finally offer you to download the LocalSettings.php file, that contains all the decisions you've made. You can review and adjust it futher and finally save it to the same folder as your docker-compose.yml file. Refresh the site and it should be accessible right away. I would say for a closed audience, these are the most important options to set:

# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;

These options will prevent people from creating their own accounts (you will have to create one for them from the UI) and it will block people from viewing any pages without being logged in.

If you do not wish to use SQlite but rather a dedicated DBMS (I strongle discourage you from getting into that trouble for smaller or even medium user bases), you will find more information on the page for alternative configuration recipes.

If you would like to go into part 2, just ask and I'll give you an overview of my setup here as well. I'm using docker-letsencrypt-nginx-proxy-companion.