Tag Archives: MySQL

Linux HOWTO

Host Your Own WordPress Site

Leave a comment

Introduction

A while back I decided to host my blog on my own servers and cut the cord with WordPress.com. There were no hard feelings really; I just didn’t like the limited options for plugin choices I had. I didn’t like all the extra features they forced me to use that made my blog (response time) slower.

The standalone version of WordPress is much more scaled down and fits my requirements better. The standalone version also allows me to pick and choose from a sea of amazing plugins at my disposal.

Prerequisite

You’ll need to have full (Linux) shell access to the server you’re intending to host this from. I set up my hosting using a CentOS 6.x machine; therefore the instructions I identify here are for that. That said, the instructions won’t stray too far off (requiring a tweak here an there) from those people who choose to use other Linux distributions.

You’ll want to first install a few packages:

# You'll basically need PHP, MySQL 
# As root (or a user with sudoer's permission) type the following:
sudo yum -y install php-fpm php-mbstring php-mcrypt \
             php-mysql nginx mysql mysql-server gawk \
             openssl

Optional FTP Support

FTP support is really nice to have with a WordPress setup! You can use it to automate the installation of plugins through the admin page. This is great for situations where you’re setting up a WordPress account for someone who isn’t too teksavvy. It also allows grants your users enough access to install plugins through WordPress’s administration interface.

I strongly suggest you read my blog entry on Configuring and Installing VSFTPD on CentOS 6 if you’re interested in going this route.

It’s important to note that WordPress functions just fine without an FTP(S) server too!

Step 1 of 8: Prepare our Environment.

To make life really easy (so you can cut and paste this right to your command line without any effort at all), lets create some environment variables.

Please note that this step MUST be ran before any of the other steps are. If you’re returning to this blog entry to resume from a step you left off at, be sure to apply these environment variables again!

Please note that you must be root or have sudoer’s permission to be able to perform any of these tasks successfully on your server.

# Our WordPress user
WPUSER=nuxref

# The FQD you will be serving your data from.  If you
# don't have your own domain, then set this to an
# underscore '_' (without the quotes '')
WPURL=nuxref.com

# Some Database Information
# - what are we going to call our database name?
DBNAME="wordpress_$WPUSER"
# - it's easier to just use the WordPress user account here
#   but if you want to change it to something else; here is
#   where you can do it:
DBUSER=$WPUSER
# - we will want to create a confusing password that others
#   can't guess. I don't recommend you use what i've identified
#   here because anyone else who knows you read my blog will
#   guess this first.  But here is where you should set your
#   database password you intend to use.
DBPASS="v3ryC0nFU51Ng-Pw%"

# If you plan on creating an FTP Account; you'll want to
# populate these variables too. This account does not have
# to be the same as the $WPUSER account. In fact making it
# different (even just slightly) would be a good idea!
# Below i just add '-ftp' to the end of the already
# determined user above.  Feel free to change this.
WPFTPUSER="$WPUSER-ftp"
# Set an FTP password; It would be a good idea to not use
# the one identified below as it's merely display only.
# some special character don't work with VSFTPD (like '!')
# if you plan on using it .
WPFTPPASS="4nt3rP455%rd"

# The following is only used for our SSL Key Generation
COUNTRY_CODE="7K"
PROV_STATE="Westerlands"
CITY="Lannisport"
SITE_NAME="Life as a Lannister"

Step 2 of 8: Create our User Account

You’ll want to create an isolated environment for our client (or you) to work within. By securing an environment; in the event anything is ever compromised, destruction will be limited to what we allow our client access to.

# First create a system directory to host our project.
sudo mkdir -p /opt/$WPUSER/html/static

# Create a dummy, favicon.ico file for now. If you feel
# ambitious, Google this if you're not sure what it's for
# so you can place your own custom one here
touch /opt/$WPUSER/html/static/favicon.ico

# Create System User
sudo useradd nuxref -M --system \
   --comment "$WPUSER WordPress Account" \
   --home /opt/$WPUSER \
   --shell /sbin/nologin

# Secure our new directory we created
chmod 711 /opt/$WPUSER
chown -R $WPUSER.$WPUSER /opt/$WPUSER

If you’ve followed my blog on Securing and Protecting Your CentOS 6 System then you might have wisely chosen to set up disk quotas. If not; then you can skip over to the next step.

# Detect the device using our home directory
DEV=$(df -l -P /opt/$WPUSER | awk 'END{print $1}')
# Restrict Users Disk Quota to 600MB
sudo setquota -u $WPUSER 180000 600000 0 0 $DEV

Step 3 of 8: Generate SSL Keys

We need to generate some Secure Socket Layer (SSL) keys so that we can provide a secure connection for logins. Otherwise our passwords we choose to work with the site could be exposed.

To make things simple, you can use my genssl tool first discussed in an earlier blog I wrote here. available for download from my github page and then just do the following:

# Generate a self signed key:
genssl -s $WPURL
# Install it:
sudo install -m 0400 $WPURL.key /etc/pki/tls/private/$WPUSER.key
sudo install -m 0444 $WPURL.crt /etc/pki/tls/certs/$WPUSER.crt

Or you can simply do the following:

# The following will generate SSL Keys (if you don't have any already)
sudo openssl req -nodes -new -x509 -days 730 -sha256 -newkey rsa:2048 
   -keyout /etc/pki/tls/private/$WPUSER.key 
   -out /etc/pki/tls/certs/$WPUSER.crt 
   -subj "/C=$COUNTRY_CODE/ST=$PROV_STATE/L=$CITY/O=$SITE_NAME/OU=IT/CN=$WPURL"
 
# Permissions; protect our Private Key
chmod 400 /etc/pki/tls/private/$WPUSER.key
 
# Permissions; protect our Public Key
chmod 444 /etc/pki/tls/certs/$WPUSER.crt

Step 4 of 8: Install our WordPress Bundle

Now we need to Download and install WordPress into our environment.

# WordPress Configuration
# Acquire latest version from here https://wordpress.org/download/
# (At the time it was 4.4.2)
wget --no-check-certificate https://wordpress.org/latest.tar.gz -O wordpress.$(date +'%Y.%m.%d').tgz

# Extract our downloaded copy
sudo tar xvfz wordpress.$(date +'%Y.%m.%d').tgz \
    -C /opt/$WPUSER/html --strip 1

# Apply some more permissions
sudo find /opt/$WPUSER/html -type d -exec chmod 755 {} \;
sudo find /opt/$WPUSER/html -type f -exec chmod 664 {} \;
sudo find /opt/$WPUSER/html -exec chown $WPUSER.apache {} \;

# Grant write permissions to a few tools our plugin installers
# will need access to later on:
find /opt/$WPUSER/html/wp-content/ -type d -exec chmod 775 {} \;
sudo chmod 660 /opt/$WPUSER/html/wp-config.php

Step 5 of 8: Configure and Prepare our Database

Now we need to configure our MySQL (or MariaDB) database. First make sure it is running:

# The below command will start the database if it isn't
# already running:
sudo service mysqld status &>/dev/null || \
   sudo service mysqld start

# Next make sure you're system is configured to start
# the database each and every time your server turns on
sudo chkconfig --level 345 mysqld on

Now we need to prepare our database that WordPress can use.

# SQL Initialization
( cat << _EOF
CREATE DATABASE $DBNAME;
GRANT ALL PRIVILEGES ON $DBNAME.* TO "$DBUSER"@"localhost" IDENTIFIED BY " $DBPASS";
FLUSH PRIVILEGES;
_EOF
) | sudo mysql

Step 6 of 8: Configure our Web Hosting Service

Okay now we need to host our website. Effectively linking the database we just prepared with the WordPress software we just installed. We do this as follows using NginX:

# By default (assuming a CentOS installation), we can
# plug into our configuration by writing our data in
# /etc/nginx/conf.d/
# So lets do just that:
cat << _EOF > /etc/nginx/conf.d/wordpress_$WPUSER.conf
#
# $WPUSER WordPress Web Hosting
#
server {
    # Support Web Traffic at port 80
    listen       80;
    server_name  $WPURL;
    root   /opt/$WPUSER/html;

    # Our log files
    access_log  /var/log/$WPUSER/$WPUSER.access.log  main;
    error_log  /var/log/$WPUSER/$WPUSER.error.log;

    # Our main handler
    location / {
        root   /opt/$WPUSER/html;
        index  index.html index.htm index.php;
        # Support Permalink changes
        try_files \$uri \$uri/ /index.php?q=\$request_uri;
    }

    # Anyone logging into our site should do it securely
    location /wp-admin/ {
       # Always redirect to secure site
       rewrite ^/(.*) https://$host/\$1 permanent;
    }
    location /wp-login/ {
       # Always redirect to secure site
       rewrite ^/(.*) https://\$host/\$1 permanent;
    }

    error_page  404              /404.html;
    location = /404.html {
        root   /usr/share/nginx/html;
    }

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # Support the favicon (for those wanting to use it)
    location = /favicon.ico {
        root   /opt/$WPUSER/html/static;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php\$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  \$document_root\$fastcgi_script_name;
        include        fastcgi_params;
    }

    # Deny access to the wp-config file
    location ~ /wp-config\.php {
        deny  all;
    }
}

server {
    # We should listen on a secure URL too so that we can
    # hide our admin login credentials from prying eyes
    listen       443;
    server_name  $WPURL;
    root   /opt/$WPUSER/html;

   ssl on;
   ssl_certificate /etc/pki/tls/certs/$WPUSER.crt;
   ssl_certificate_key /etc/pki/tls/private/$WPUSER.key;
   ssl_session_timeout  5m;

   # Secure our site by only allowing the TLS protocol
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK';
   ssl_prefer_server_ciphers on;
   ssl_session_cache  builtin:1000  shared:SSL:10m;

   access_log  /var/log/nginx/$WPUSER.access.log  main;
   error_log  /var/log/nginx/$WPUSER.error.log;

   location / {
      root   /opt/$WPUSER/html;
      index  index.html index.htm index.php;
      # Support Permalink changes
      try_files \$uri \$uri/ /index.php?q=\$request_uri;
   }

   error_page  404              /404.html;
   location = /404.html {
      root   /usr/share/nginx/html;
   }

   # redirect server error pages to the static page /50x.html
   #
   error_page   500 502 503 504  /50x.html;
   location = /50x.html {
       root   /usr/share/nginx/html;
   }

   # Handle favicon
   location = /favicon.ico {
       root   /opt/$WPUSER/html/static;
   }

   # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
   #
   location ~ \.php\$ {
      fastcgi_pass   127.0.0.1:9000;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME  \$document_root\$fastcgi_script_name;
      include        fastcgi_params;
   }

   # Deny access to the wp-config file
   location ~ /wp-config\.php {
      deny  all;
   }
}
_EOF

Now restart our web services

# Ensure our web browser and php handler will start
# even if our server is restarted
chkconfig --levels 345 php-fpm on
chkconfig --levels 345 nginx on

# The following just makes sure we reload and take
# on our new configuration.  If we're not running
# then we start the services up
service php-fpm status &>/dev/null && \
   service php-fpm restart || \
   service php-fpm start

service nginx status &>/dev/null && \
   service nginx restart || \
   service nginx start

Step 7 of 8: Optionally Setup an FTP Account

Most people can skip this step; it again presumes you’ve followed my other blog on Configuring and Installing VSFTPD on CentOS 6. If you have not gone here or have set up FTP your own way, you can also skip this step and move on with Configuring WordPress.

# Create a WordPress Plugins FTP Account
echo $WPFTPUSER >> /etc/vsftpd/users.passwd
echo $WPFTPPASS >> /etc/vsftpd/users.passwd
 
# Protect Password
chmod 600 /etc/vsftpd/users.passwd
chown root.root /etc/vsftpd/users.passwd
 
# Now convert content into a db structure
db_load -T -t hash -f /etc/vsftpd/users.passwd /etc/vsftpd/virtual.users.db
chmod 600 /etc/vsftpd/virtual.users.db
chown root.root /etc/vsftpd/virtual.users.db
 
cat << _EOF > /etc/vsftpd/virtual.users/$WPFTPUSER
local_root=/opt/$WPUSER/html
# -------------------------------------------------------------------------
# User
# -------------------------------------------------------------------------
guest_enable=YES
guest_username=apache
local_root=/opt/$WPUSER/html
# -------------------------------------------------------------------------
# Permissions
# -------------------------------------------------------------------------
# write_enabled is required if the user is to make use of any of the
# anon_* commands below
write_enable=YES
# give the user the ability to make directories
anon_mkdir_write_enable=YES
# give the user the ability delete and overwrite files
anon_other_write_enable=YES
# give the user the ability upload new files
anon_upload_enable=YES
# Give the user permission to do a simple directory listings
dirlist_enable=YES
# Give the user permission to download files
download_enable=YES
# if the user has can upload or make new directories, then this will be
# the umask applied to them
anon_umask=0002
# delete failed uploads (speaks for itself)
delete_failed_uploads=NO
_EOF
 
sudo chmod 600 /etc/vsftpd/virtual.users/$WPFTPUSER
sudo chown root.root /etc/vsftpd/virtual.users/$WPFTPUSER

# Ensure our FTP Server will restart if our server
# is ever restarted:
sudo chkconfig --level 345 vsftpd on
# Update Service (to read in new configuration)
sudo service vsftpd status &>/dev/null && \
    service vsftpd restart || \
    service vsftpd start

Step 8 of 8: Configure WordPress

If you successfully pulled off all of the earlier steps, then you shouldn’t have any trouble from this point forward. The hard part is done with!

Wordpress Database SetupWordpress InstallationYou now need to open up your browser and access your new WordPress website to continue with the setup. Simply visit your website by browsing to http://your.wordpress.url/ (whatever you set this up as).

First you’ll be immediately presented with webpage that needs some information about the database we set up back in Step 5 (an environment variables defined in Step 1.

After you press the [Submit] button, you’ll then be asked to define some basic information about the blog you intend to set up. You can change all this later, so don’t worry. The important fields here are the administrator user and password you create.

You’re done now and ready to use WordPress

Great WordPress Plugins

The following plugins are worthy of a mention:

Credit

Please note that this information took me several days to put together and test thoroughly. I may not blog often; but I want to re-assure the stability and testing I put into everything I intend share.

If you like what you see and wish to copy and paste this HOWTO, please reference back to this blog post at the very least. It’s really all I ask.

Linux HOWTO

Configuring and Installing MediaWiki on CentOS 6

2 Comments

Introduction

Wiki’s have got to be the easiest and fastest way to collaborate documents, thoughts, ideas, howto’s etc. In fact, everything I’ve blogged about is mostly cut and copied from my own personal Wiki I maintain on my private network to help me keep track of things.

There are lots of wiki solutions, but I personally like MediaWiki which uses a relational database on it’s back end. It’s also has a strong background as it’s widely used by the most popular wiki’s being hosted today. Here is how MediaWiki defines itself official (quoted directly from their website):

MediaWiki is a free software open source wiki package written in PHP, originally for use on Wikipedia. It is now also used by several other projects of the non-profit Wikimedia Foundation and by many other wikis..

There are tutorials everywhere for this; why make another?
As an administrator/developer myself, I like to eliminate as many steps as I can and make things as easy as possible. I also like to let the operating systems chosen package management software do most (if not all) of the work if possible. So unlike other tutorials; this solution will do most of the work for you out of the box. I have packaged a self installing RPM that prepares MediaWiki along with some useful extensions. Package management and version control is the real seller I think.

Whatever, just give me all of your software

This is what my blogs usually boil down to… so here is the data:

For those who want to rebuild from source and do not trust my rpm will need to perform the following:

# If you haven't got mock configured and installed by this point,
# it's probably better if you read one of the previous blogs I've
# posted where I show how to set it up.  To keep this blog shorter
# i'm going to refrain from explaining this step.
# Since this tutorial supports both CentOS/EPEL 5 and 6 set the
# version we're interested in:
VER=6

# Download the packages we need to make this happen:
# 1. MediaWiki itself
wget http://download.wikimedia.org/mediawiki/1.21/mediawiki-1.21.2.tar.gz
# 2. WYSIWYG, manually get it here: 
# https://docs.google.com/file/d/0B-aiZzKTmWI2bG8yVzBCOWNLamM/view?pli=1
# or keep using wget for speed (I copied it since I couldn't find a way
# to direct link to a google drive location).
wget --output-document=WYSIWYG_MW_v1.20.2.zip https://www.dropbox.com/sh/9dt7klam6ex1kpp/f79PvTQ_g7/20131105/mediawiki/WYSIWYG_MW_v1.20.2.zip?dl=1
# 3. WYSIWYG patch #1
wget --output-document=wysiwyg.cancel.fix.patch https://www.dropbox.com/sh/9dt7klam6ex1kpp/qxTV7Duu8G/20131105/mediawiki/wysiwyg.cancel.fix.patch?dl=1
# 4. WYSIWYG patch #2
wget --output-document=mw-1.21.compatible.patch https://www.dropbox.com/sh/9dt7klam6ex1kpp/qoOCF2P16A/20131105/mediawiki/mw-1.21.compatible.patch?dl=1
# 5. The RPM SPEC file
wget --output-document=mediawiki.spec https://www.dropbox.com/sh/9dt7klam6ex1kpp/Cv9_1FynJ-/20131105/mediawiki/mediawiki.spec?dl=1
# 6. A seperate package labeled as extras (which right now
#    just contains a working Secure Apache configuration file)
#    but could be subject to change later such as supporting
#    Lighthttpd and NginX.
wget --output-document=extras.tar.gz https://www.dropbox.com/sh/9dt7klam6ex1kpp/2R7BZSuXYW/20131105/mediawiki/extras.tar.gz
# Initialize our Environment (I hope your set the $VER
# variable above)
mock -v -r epel-$VER-x86_64 --init

# Copy in our downloaded content:
mock -v -r epel-$VER-x86_64 --copyin mediawiki.spec 
   /builddir/build/SPECS
mock -v -r epel-$VER-x86_64 --copyin 
   mediawiki-1.21.2.tar.gz 
   WYSIWYG_MW_v1.20.2.zip 
   extras.tar.gz 
   mw-1.21.compatible.patch 
   wysiwyg.cancel.fix.patch 
   /builddir/build/SOURCES

# Shell into our enviroment
mock -v -r epel-$VER-x86_64 --shell

# Change to our build directory
cd builddir/build

# Build our RPMS
rpmbuild -ba SPECS/mediawiki.spec

# we're now done with our mock environment for now;
# Press Ctrl-D to exit or simply type exit on the
# command line of our virtual environment
exit

# Grab our packages (v6):
[ "$VER" == "6" ] && 
  mock -v -r epel-6-x86_64 --copyout 
     /builddir/build/SRPMS/mediawiki-1.21.2-1.el6.src.rpm .
[ "$VER" == "6" ] && 
  mock -v -r epel-6-x86_64 --copyout 
   /builddir/build/RPMS/mediawiki-1.21.2-1.el6.noarch.rpm .

# -or- Grab our packages (v5):
[ "$VER" == "5" ] && 
  mock -v -r epel-5-x86_64 --copyout 
   /builddir/build/SRPMS/mediawiki-1.21.2-1.el5.centos.src.rpm .
[ "$VER" == "5" ] && 
  mock -v -r epel-5-x86_64 --copyout 
   /builddir/build/RPMS/mediawiki-1.21.2-1.el5.centos.noarch.rpm .

Package Information

  • Software installs to: /usr/share/mediawiki
  • Apache configuration placed in: /etc/httpd/conf.d/mediawiki.conf and can be previewed here.
  • WYSIWYG Extension is additionally packaged as an extra for those who wish to use it. The installer will give you the option of adding this. I’ve already applied all of the necessary patches they’ve listed on their website to make it work correctly with MediaWiki v1.21.2. You can view the patch files I created here and here.
  • CentOS/RHEL 5 also supported if you want:

    Keep in mind that MediaWiki requires a bare minimum of PHP v5.3 (and a minimum PostgreSQL v8.4 for those database fans like me). These packages are all available to CentOS 5 users right out of the box and Red Hat 5 users through the EPEL packages.

Installation Information

Identified below outline the 3 steps necessary to get up and going.

Installation Step 1 of 3: Choose Your Database Backend:

First thing is first, you need to choose a database back end. This tutorial will use PostgreSQL because to me, that is the best and most underrated open source database available today. That said, I’ve identified how to install the other open source choices below. You’ll need to have satisfied at least one of the below options before you can proceed.

  • 1. MySQL: 
    # Install Dependencies (if they're not already)
yum install mysql-server mysql php-mysql
# Enable Server (if it's not already)
# Set MySQL to restart at system startup
chkconfig --level 345 mysqld on
# Start MySQL (if it's not already)
service mysqld start
# Reload Apache (needed if php-mysql was added above)
service httpd reload
  • 2. SqlLite: 
    # Install Dependencies (if they're not already)
yum  install sqlite php-sqlite
# Reload Apache (needed if php-sqlite was added above)
service httpd reload
  • 3. PostgreSQL: 
    # Install Dependencies (if they're not already)
yum install postgresql postgresql-server php-pgsql
# Enable Server (if it's not already)
# Set MySQL to restart at system startup
chkconfig --level 345 postgresql on
# Start PostgreSQL (if it's not already)
# If this is your first time starting it; it may require you to run
# the following: service postgresql initdb
# Note: Do not run 'initdb' if your database is already configured
#       or you will reset it and lose it's contents.  But you are
#       required the call it the first time.
service postgresql start
# Reload Apache (needed if php-pgsql was added above)
service httpd reload
# You may need to additional set up some security to allow Apache
# access to your database.  Depending on your knowledge, the
# below command may or may not satisfy your needs. But as a quick
# and dirty solution to gain immediate access to the database
# (and greatly simplifies this tutorial), I'd advise people to
# run the following:
sed -i -e 's/^[ t]*(local|host)([ t]+.*)/#12/g' 
    /var/lib/pgsql/data/pg_hba.conf
cat << _EOF >> /var/lib/pgsql/data/pg_hba.conf
# Configure all local database access with trust permissions
local   all         all                               trust
host    all         all         127.0.0.1/32          trust
host    all         all         ::1/128               trust
_EOF
# Restart the Database so it takes on the new Client
# Authentication identified above
service postgresql restart

Your installation will not change that significantly if you did not pick PostgreSQL as your chosen backend identified above. In fact, it may even be easier to install since other databases have fewer security restrictions. You can still follow through with the actions explained below.

Installation Step 2 of 3: Install The MediaWiki Package:

# Install Dependencies (if they're not already)
# At the present time I do not generate a GPG signature, so without
# the --nogpg check yum will tell you it can't install the package.
yum localinstall mediawiki-1.21.2-1.el6.noarch.rpm --nogpg

# Of if using CentOS/RHEL 5 you can type the following:
# yum localinstall mediawiki-1.21.2-1.el5.centos.noarch.rpm --nogpg

# Reload Apache (needed if php-sqlite was added above)
service httpd reload

# If you're using SELinux, then you will have to enable access
# to your database from Apache (if you haven't already). Otherwise
# you will receive errors about not being able to connect to
# your database during the setup stage.
semanage boolean -m --on httpd_can_network_connect_db
# for uploading (specifically to images/), this works best:
semanage fcontext -a -t httpd_sys_content_t '/usr/share/mediawiki(/.*)?'
restorecon -R /usr/share/mediawiki
Here is what should be displayed to if you installed the mediawiki RPM and visit http://localhost/wiki
Here is what should be displayed if you installed the mediawiki RPM and visit http://localhost/wiki

Configure MediaWiki

You MUST complete "Installation Step 2 of 3" defined above or you"ll receive this error message!
You MUST complete ‘Installation Step 2 of 3’ defined above or you’ll receive this error message!
Your screen does not have to look exactly like this; but the most important part is where it tells you that "The environment has been checked. You can install MediaWiki".
Your screen does not have to look exactly like this; but the most important part is where it tells you that “The environment has been checked. You can install MediaWiki”.

If you’re reading this far, then you’ve completed both of the installation steps above. Now we want to configure MediaWiki which is now already available to you. You can access it by opening a browser and visiting: http://localhost/wiki. Alternatively, if your doing this remotely, substitute localhost for your sites hostname or IP address. You should be presented with a webpage that looks similar to the screenshot presented here. You’ll want to click on the link that says complete the installation to set the Wiki up for your environment style.

Follow through the wizard answering all the questions asked of you. If you’re unsure of any answers to the questions being asked, usually the default answers are satisfactory enough.

Installation Step 3 of 3: The LocalSettings.php

When you've successfully completed the configuration you will be asked to download LocalSettings.php
When you’ve successfully completed the configuration you will be asked to download LocalSettings.php
When you’ve completed the wiki’s installation wizard, it will ask you to save/download a file entitled LocalSettings.php. This file contains all the information the wiki needs to work with. You MUST download this file and copy it to /usr/share/mediawiki.

# Copy LocalSettings.php into the mediawiki's installation
# directory; This step is crucial!
cp LocalSettings.php /usr/share/mediawiki

# Update it's permissions for security sake!
chown root.apache /usr/share/mediawiki/LocalSettings.php
chmod 640 /usr/share/mediawiki/LocalSettings.php

LocalSettings.php becomes the final piece of the puzzle; it contains all of the options you choose and will instruct your wiki how to behave. Once this file is in place, you’re finished with the setup! 🙂

You can access your wiki and record and collaborate information to your hearts content!

The Apache configuration file that is included with this bundle is smart enough to detect the LocalSettings.php file and switch to it’s full out Wiki mode. Now when you visit your website (http://localhost/wiki) you can begin molding it to your liking. Note that the Apache configuration file included additionally adds support for colons (:) in your wiki paths. This allows you to create wiki’s such as: http://localhost/wiki/MySpecialWikiPage:That:Uses:Colons. Colon’s really make it so your wiki can mold and organize itself like the most popular wiki (Wikipedia.org) website used today.

Backups

Always consider that the worst can happen, you should:

  • Take regular backups of your database
  • Make backups of the /usr/share/mediawiki/images directory at the same time as your database backups since this is where other media content can get uploaded to
  • Store your LocalSettings.php you recently downloaded along with the mediawiki rpm package somewhere safe so you can always easily recover.

July 17th, 2014 Update
Since this blog was written newer versions of MediaWiki came out along with my repository I host. For those who want to update to the newer version (or just starting out and want to fetch the latest version) you can get it there.
You can also just download it directly here:

Just note that I scrapped the WYSIWYG plugin and all the patches I made for it in this release. I did this simply because it’s just getting too dated and no one is updating it anymore. If it’s the first time reading this blog or you’re retrieving MediaWiki for the first time, then this blog and it’s content still applicable (except WYSIWYG references) to the newer version.
For those of you who already are running a version of MediaWiki and want to upgrade. Upgrade instructions can be found here. Alternatively, if you’re simply upgrading from the version identified in this blog (v1.21), just run the following after you install the new rpm (and then you’re good to go!):

# Consider making a database backup snapshot of your wiki 'just in case'
# I didn't have any problems at all, but it doesn't mean you won't.
# Better safe then sorry... right?

# As root, upgrade your mediawiki package
yum upgrade -y mediawiki --disablerepo=* 
   --enablerepo=nuxref 
   --enablerepo=nuxref-shared

# Eliminate any reference to WYSIWYG since it will be gone now
sed -i -e 's|^([^#]+extensions/WYSIWYG/WYSIWYG.php.*)$|#1|g' 
    /usr/share/mediawiki/LocalSettings.php

# Run Upgrade Script
php /usr/share/mediawiki/maintenance/update.php

# Protect /usr/share/mediawiki/mw-config/ from access
chown root.apache /usr/share/mediawiki/mw-config/
chmod 700 /usr/share/mediawiki/mw-config

Another thing you might want to do is bump the file sizes you intend to upload (especially if you’re going to allow .zip, .rar. etc extensions onto your wiki):

# optionally support extra file extensions that can be uploaded:
cat << _EOF >> /usr/share/mediawiki/LocalSettings.php
$wgFileExtensions = array_merge(
    $wgFileExtensions, array(
        'pdf', 'doc', 'docx', 'xls', 'xlsx',
        'rpm', 'tar', 'zip', 'tgz', 'gz',
        )
    );
_EOF

sed -i -e 's/^(upload_max_filesize *=).*/1 100M/g' /etc/php.ini
sed -i -e 's/^(post_max_size *=).*/1 100M/g' /etc/php.ini

# Reload service
service httpd reload

Credit

Please note that this information took me several days to put together and test thoroughly. I may not blog often; but I want to re-assure the stability and testing I put into everything I intend share.

If you like what you see and wish to copy and paste this HOWTO, please reference back to this blog post at the very least. It’s really all I ask.

Sources

  • I used mediawiki.org and view the ideal setup configurations as well as read through peoples notes and work arounds. Note: At the time this blog was created v1.21.2 was the current stable version, so that is what was packaged.
  • WYSIWYG Extension is also packaged in the RPM I provided. I created 2 small patches using the comments here and here.