Tag Archives: Centos

Linux HOWTO

Secure and Protect Your CentOS 6 System

1 Comment

Introduction

Security is important these days but sadly there are a scary amount of blogs and comments from people out there who solve their problems by turning off their firewall and/or disabling SELinux. These steps may work around a problem, but it will make your system much more vulnerable to cyber attacks. Learning alternative ways of solving your applications woes without disabling key safety components on your system is a better approach to keeping it secure. The goal of this blog is to offer a quick primer on some key security components that will protect you an your data!

The topics covered in this blog to keep your systems secure are:

  • Fail2Ban
    Intrusive detection and prevention
  • Firewall
    The front line to the internet (where all the bad stuff happens)
  • Restricting SSH Access
    A couple tweaks to help bulletproof yourself from possible intrusion.
  • System Auditing
    Find out what got accessed and by who and what major system calls were made.
  • System Monitoring
    Monitor your system for key things that could be symptoms of a hacked or compromised system.
  • Enable SELinux
    This is literally your last line of defense, and its a lot better then people make it out to be.
  • Disk Quotas
    Prevent a user from violating disk space on a production system.

Fail2Ban

For those of you who run a system on the front end of the internet have to deal with firewalls and security. Fail2Ban is a python based tool that wraps itself around iptables. It’s can cleverly watch system log files and detect abuse; it then proceeds to temporary (or permanently) block/ban the culprit by using their IP address in conjunction with your firewall.

At the time I blogged this, Fail2Ban was in the pre-release stages of v0.8.11. For this reason I’ll focus on v0.8.10.

Get the Software
Now the EPEL Repositories already provide us with software to do the installation here (and source rpm here).

Alternatively, I rebuilt the source myself and am hosting it here (in case the version changes significantly enough that this tutorial no longer works). My hosted version of version of Fail2Ban rpm can be retrieved here (and source rpm here).

Setting Up Fail2Ban

# Configure epel (if not already)
rpm -Uhi http://fedora.mirror.nexicom.net/epel/6/i386/epel-release-6-8.noarch.rpm

# Install the goods
yum -y install fail2ban

# Optionally install 'jwhois'. This tool gives you great detail on people
# accessing your system by performing a whois lookup on them and including
# the results of this in the automated email sent. Honestly it's worth it.
yum -y install jwhois

Out of the box the settings will work with SSHD only and for now that is all I need. However I’ve made it a bit more restrictive to satisfy my needs:

# Create a backup of our original configuration files before we apply
# any changes to them:
[ ! -f /etc/fail2ban/fail2ban.conf.orig ] && \
   cp -af /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.conf.orig
[ ! -f /etc/fail2ban/jail.conf.orig ] && \
   cp -af /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.orig

# var/log/messages is busy enough; I prefer to use
# /var/log/fail2ban.log personally (it's already pre-configured
# with a logrotate.d entry to accommodate this)
sed -i -e 's|^logtarget[ t]=.*|logtarget = /var/log/fail2ban.log|g' \
	/etc/fail2ban/fail2ban.conf

# The below ;'sed' commands only change the first occurrence in the file
# # which is where the [default] is identified
# Default Ban for 1 day (86400 seconds = 1 day)
sed -i -e '0,/^bantime[ t]*=.*/s//bantime = 86400/' \
	/etc/fail2ban/jail.conf

# Default Ban if more then 3 unsuccessful attempts are made within 30 min
# (1800 seconds = 30 min).
sed -i -e '0,/^maxretry[ t]*=.*/s//maxretry = 3/' \
	/etc/fail2ban/jail.conf
sed -i -e '0,/^findtime[ t]*=.*/s//findtime = 1800/' \
	/etc/fail2ban/jail.conf

# These IPs don't conform to our very restrictive checks and will
# bypass the Fail2Ban security. For my own personal privacy, I've
# adjusted them from my own personal IPs. You might want to change
# this to reflect what you want (use spaces to delimit them). You
# can use masks too such as 10.128.3.0/16 (adding the slash (/)).
# but remember you need to escape () the slash in the below
# sed statement.  For example, the below will add the following:
#     127.0.0.1, 1.2.3.4, and 7.8.9.0/24
#
# Note: At a minimum, make sure to include 127.0.0.1
sed -i -e '0,/^ignoreip[ t]*=.*/s//ignoreip = 127.0.0.1 1.2.3.4 7.8.9.0\/24/' \
	/etc/fail2ban/jail.conf

# Configure the system to start fail2ban after every reboot
chkconfig --levels 345 fail2ban on

# Start it up now for the first time (use 'restart' instead
# of 'start)' if it was already running:
service fail2ban start

There are lots of configurations already available that ship with this tool (but disabled by default). Have a look at /etc/fail2ban/jails.conf, perhaps there are others you might be interested in. If you’re uncertain what some of them are, or what they do; just have a look at the fail2ban manual.

Firewall / iptables

This literally your front line runner to all the security between you and the violent internet. Your firewall is your only shield and one of the last line of defense you have in some scenarios. SELinux would be the last line of defense you have which I talk about later. If troubleshooting a product has boiled down to stopping your firewall, then you’ve done something horribly wrong. There are other ways to debug firewall issues and stopping it shouldn’t be one of them.

Try running the following command just to see what ports your system is already listening on:

# The below lists all listening connections that could be
# being access remotely if your firewall is disabled
#
netstat -pnat | egrep LISTEN | 
   tr -s ' ' | cut -f4,7 -d' ' | sed '/^0.0.0/d'

It’s the above list you’re trying to protect! It’s not uncommon for an application to communicate to another through ip (such as a database does); but these ports do not need to be open to the entire internet!

Setting Up a Simple Firewall
Here is a very simple firewall you can use to get you started:

# Set this to your internet interface (it might be ppp0 too)
# run ifconfig to see what interfaces you have
PUBLIC=eth0
cat << _EOF > /etc/sysconfig/iptables
#
# A Simple firewall that allows access to SSH and Web Based inbound
# connections but will allow you to access everything outside
#
*filter
#---------------------------------------------------------------
# Drop Everything by default
#---------------------------------------------------------------
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

#---------------------------------------------------------------
# Internal Traffic is Okay
#---------------------------------------------------------------
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

#---------------------------------------------------------------
# Always accept already established connections
#---------------------------------------------------------------
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#---------------------------------------------------------------
# Deny traffic from internet that spoofs addresses used internally
#---------------------------------------------------------------
-A INPUT -i $PUBLIC -s 192.168.0.0/24 -j DROP
-A INPUT -i $PUBLIC -s 127.0.0.0/8 -j DROP
-A INPUT         -d 10.0.0.0/8 -j DROP
-A INPUT         -d 169.254.0.0/16 -j DROP

#---------------------------------------------------------------
#  All Outbound Traffic Accepted (for now)
#---------------------------------------------------------------
-A OUTPUT -o $PUBLIC -j ACCEPT

#---------------------------------------------------------------
# SSH Allowed
#---------------------------------------------------------------
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

#---------------------------------------------------------------
# Web Traffic Allowed
#---------------------------------------------------------------
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

#---------------------------------------------------------------
# The default is to drop everything else
# but for read-ability and peace of mind
# we force it again anyway
#---------------------------------------------------------------
-A INPUT -i $PUBLIC -j DROP
-A FORWARD -i $PUBLIC -j DROP

# End
COMMIT
_EOF

# Now restart iptables for the new rules to take affect
service iptables restart

# If you're running fail2ban then you'll need to restart it too
# since the extra chains it creates into iptables would have just
# got wiped with the last command.  Restarting it will rebuild
# everything the way it should be
service fail2ban restart

# Ensure this file is not accessible by anyone
chmod 600 /etc/sysconfig/iptables

When or if you add a new program into your environment, it should just work… if you need to share or host it’s services to others, find out what ports it uses and ‘ONLY’ open them. Consider the security risks that become available to you once these ports are open to the world as well. Hence you are putting all your trust in the application listening on every port you open. Also note that every port your open is a potential point of entry a hacker can use into your system.

Restrict SSH Access

SSH is a great way for you to connect remotely to your server and see how things are going, make changes etc. But consider other people (whom you don’t know) might be trying to access it also (usually for malicious reasons). If you’ve set up fail2ban already, then you’re already in really good shape. But consider restricting the the SSH Daemon even more for precautionary reasons. Here is what I’m suggesting:

  • Disable remote SSH access for the root user login: 
    # Before you do this, be sure you have an non-root account you
# can still connect to the system as that you will use instead of
# root
useradd nuxref
# I always add my users to the users group, you don't have to do
# this:
usermod -G users nuxref
# Set a password for the user you created
passwd nuxref

# In the above example I can use 'nuxref' as an entrance into the
# system to which I can switch to the root after I establish a
# my connection.
# 90% of the constant connections your server will face when
# directly connected to the internet will be as the 'root' user.
# So why even bother enabling that account? Fail2Ban will end up
# blocking them shortly anyway, but why even give them 3 lucky
# guesses? It's really not worth it. It's much safer to use another
# account and switch to root if needed later.

# This also means that if for some miraculous reason someone
# guesses your non-root account to gain access to the system, the
# damage they can do will be as minimal as the access you've given
# that account.

# Now Deny Root Login Attempts
sed -i -e 's/^[# t]*PermitRootLogin .*/PermitRootLogin no/g' /etc/ssh/sshd_config

# To prevent the system from allowing additional users you add to
# your system from accessing it remotely you'll want to consider
# doing the following:
# First get rid of an existing entry
sed -i -e '/^[# t]*AllowUsers .*/d' /etc/ssh/sshd_config
# Now add our user restrictions (if you have more then one
# user you want to add, separate them using spaces
echo "AllowUsers nuxref" >> /etc/ssh/sshd_config
  • Consider using a banner message as a warning to let people know they’ve inadvertently accessed a system they shouldn’t. Sure a hacker will ignore this message, but for the poor fellow who really did just mistype an ip or host; this will give your server some character and notify them that you are monitoring them. Nothing but a scare tactic; but it’s still worth doing. 
    # A simple scare banner
cat << _EOF > /etc/banner
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *
*                                                                             *
* The use of this system is restricted to authorized users. All information   *
* and communications on this system are subject to review, monitoring and     *
* recording at any time, without notice or permission.                        *
*                                                                             *
* Unauthorized access or use shall be subject to prosecution.                 *
*                                                                             *
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *
_EOF

# Make sure it's not accessible by others
chmod 640 /etc/banner

# SELinux Handling
restorecon /etc/banner

# Now tell the SSH Daemon to reference it:
sed -i -e 's|^[# t]*Banner .*|Banner /etc/banner|g' /etc/ssh/sshd_config
  • Disable X11 forwarding and Tcp Forwarding; These are what hackers will want to utilize if they ever successfully gain access to your system: 
    # X11 grants someone the ability to launch X applications locally
# at their machine that are associated with your server.  In some
# cases this is okay. But if you're just hosting web servers and
# databases; you shouldn't offer free candy to a potential unknown
# users who may have just connected to your production system.
sed -i -e 's|^X11Forwarding .*|X11Forwarding no|g' /etc/ssh/sshd_config
# Yet another service that just shouldn't be open no a production
# system. Someone is trying to access something they couldn't
# otherwise have done it if they're invoking this. Not saying this
# feature isn't powerful, I'm just saying disable it until you
# find a reason not to.
sed -i -e 's|^[#]*AllowTcpForwarding .*|AllowTcpForwarding no|g' /etc/ssh/sshd_config
  • Disable UseDNS reference. This is optional; I just do this because it’s faster. Also IPs are easier to scan later. The DNS lookup can slow things down sometimes which can be annoying. This isn’t a security thing at all; it just makes things faster. 
    # Disable UseDNS
sed -i -e 's|^[# t]*UseDNS .*|UseDNS no|g' /etc/ssh/sshd_config

When you’re comfortable with all your changes, you can restart the SSH Daemon to take them on. If you were logged in remotely already, don’t worry, you won’t lose your connection when you do this.

# Restart SSHD so it will reread it's configuration 
service sshd restart

Enable Auditing

If you have to resort to auditing, then your system may have already been compromised, but this will play a key role in figuring out what happened. Hopefully you’ll never have to rely on this step, but being cocky and going without it might become problematic in the future. This tool will help make your system better in the long run.

But auditing gives you something more as well; once it’s enabled you can set up the monitoring of it’s log file (/var/log/audit/audit.log) for suspicious activity. You can even go as far to write your own plugin for Fail2Ban to study the audit.log and react if certain suspicious system transaction takes place by a non-root user.

Auditing should be a considered mandatory service you implement on all of your servers.

Setting Up Some Simple Working Audit Rules
Here is a quick audit file you can use (and tailor to your liking) just to get you started; even if you added nothing else to this file, it’s configuration as is may save you one day:

# Install Auditing if it isn't already (most systems install this out of
# the box)
yum -y install audit
# Ensure your system will always run it
chkconfig --levels 345 auditd on
# Start it if it isn't already started:
service auditd status || service auditd start
# Install Audit Rules
cat << _EOF > /etc/audit/audit.rules
# First rule - delete all
-D

# increase the buffers to survive stress events. make this bigger for
# busy systems.
-b 1024

# monitor unlink() and rmdir() system calls.
-a exit,always -F arch=x86_64 -S unlink -S rmdir
# settimeofday so we know no one is adjusting the system times
-a exit,always -F arch=x86_64 -S settimeofday
# setrlimit.* so we know when kernel resources are being adjusted
-a exit,always -F arch=x86_64 -S setrlimit
# Filesystem Mounting (umount = 32bit, umount2 = 64bit)
-a exit,always -F arch=x86_64 -S mount -S umount2

#Ensure that failed use of the following system calls is audited
-a exit,always -F arch=x86_64 -S quotactl -S kill -S chroot -F success=0 -F auid=-1 -F auid=0

# some file and directory watches
-w /var/log/audit/ 
-w /etc/audit/auditd.conf -p rxwa
-w /etc/audit/audit.rules -p rxwa

# monitor write-access and change in file properties (read/write/execute)
# of the following files.
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa

# monitor write-access to the following directories
-w /etc/fail2ban -p wa
-w /etc/httpd -p wa
-w /etc/cron.d -p wa
-w /var/www -p wa

# lock the audit configuration to prevent any modification of this file.
#-e 2
_EOF

# Restart Audit To take on new configuration
service auditd restart

Now you can check for changes as root using commands like:

# Search for anyone touching the /etc/passwd file
ausearch -f /etc/passwd
# Search for anyone accessing the /etc/fail2ban/fail2ban.conf
ausearch -f /etc/fail2ban/fail2ban.conf

Don’t forget to uncomment the very last line of the /etc/audit/audit.rules if you’re using sample configuration file I have above as your template. The -e 2 will prevent someone from turning the auditing off before they wreck havoc on your system. the -e 2 will make it so a reboot is required for the rules to change. This IS what you want; trust me! Hackers aren’t stupid; disabling auditing is the first thing they’ll attempt before they begin creating their chaos.

Monitoring Strategies

I already wrote a tutorial on using Nagios here. Consider using this; it can even be configured to monitor the audit logs and set alarms off when something unusual is matched.

But consider monitoring things such as the following as well:

  • The System Load
  • Remaining Disk Space
  • Bandwidth Utilization
  • Number of Users Remotely Logged in

All of the suggestions above can help you quickly identify unusual behavior and allow you to take action immediately (instead of just the next time you happen to be on the system). Obviously you’ll know your system better than anyone else, so if you expect the system load to go high at night for certain tasks, you can consider this in your monitoring as well.

It’s the times that nothing should be out of the ordinary that an alarm could help you resolve a problem just minutes (if not seconds) after it occurs. Monitoring also works in your favour for checking other system commands such as web page availability (if you’re hosting one) etc. Find out something is wrong before your very own customers do is the key here.

In fact, there really isn’t a good reason you should ever consider snuffing monitoring from your security TODO list.

Enable SELinux

There are a lot of people who seem to be really against using SELinux when in fact it is totally amazing and really easy to work with once you understand it. The biggest problem most people have is they don’t ever take the time to learn it. Hell, even I’ll admit it’s a frustrating learning curve in it’s unknown state.

But honestly: it effectively allows you to revoke sections of your file system as well as major system calls based on the executable code (not just the user/group). Why is this so important? Well take Apache for example. If someone were to successfully compromise it from the outside (using a buffer overflow), they will have gained full user access granted to the apache user and can literally browse your entire system. Their goal would be to potentially look for other exploits that they can use to gain higher privileges (such as root access). Heck even as the Apache user, you can run quite a lot of programs including ones that access the internet.

With respect to the Apache example just explained, if the administrator had SELinux running (in Enforcing Mode) the hacker is restricted to only reading and accessing the permissions assigned to the /usr/sbin/httpd binary. At most they’d be able to view your Apache configuration file and read html files… That’s about it.

SELinux is an amazing tool for locking down your system. In fact, SELinux is your very last line of defense. If this isn’t running and an application gets compromised, you’re going to have to rely completely on your audit logs to find what damage was done to your system and attempt to repair it (hopefully from backups).

I won’t lie though, the big problem with SELinux is that the documentation is poor. Not to mention that no one really promotes it’s fantastic functionality. Instead everyone just disables it and moves on.

One of the simplest things you can do upfront when trying to work with SELinux is just keep it in enforcing mode. RHEL/CentOS packages have already looked after most of the settings for you. In the rare case something doesn’t work for you; instead of panicking and disabling SELinux (which all websites tell you to do). Set it to ‘Permissive’ mode instead. This is effectively the same as disabling it except it still records violations in /var/log/audit/audit.log what it would have otherwise denied.

# Set SELinux into Permissive mode
setenforce 0

At this point your application (that may have not worked prior to this call) may suddenly work again. It is at this point you you can begin seeing what SELinux was denying by referencing these very audit logs. These logs play a key in making everything work for you again.

Making a New Product SELinux Compatible
Take Nagios for example and the blog I did for it. This is really easy to protect and still have SELinux running in Enforcing mode. Assuming you set SELinux in Permissive mode already (explained above), you can now generate a fast set of rules to allow the product to work with it enabled. Here is how you can do it:

# First make sure you have the right package installed to work
# with:
yum install -y policycoreutils

# For alarms to be generated, you'll want to run Nagios with
# SELinux in Permissive mode for a while (preferably a day would
# be great to get everything) 

# Filter out only nagios alarms that were generated by SELinux
cat /var/log/audit/audit.log | grep denied | 
	grep nagios > nagios.audit.log

# Now tailor the file if necessary (strip out lines you don't
# want to grant access to). Use a simple editor (like vi) to do
# this. It's really not that hard to read, and the output will
# show you precisely what nagios tried to access.  In some
# cases, you may never want nagios to access these things. so
# remove these entries from this list. Only keep the denied
# messages you want to reverse (and allow)

# Create an installable Module (prefix with 'my' to avoid
# conflicts with other package management that it might be using)
audit2allow -v --input nagios.audit.log -M mynagios

## Install the new module you just created
semodule -i mynagios.pp

That’s it; now you can set SELinux back to enforcing mode for the added security it offers you:

# Set SELinux back to Enforcing mode
setenforce 1

Was that really so hard? Every now and then grep through your audit logs (like you already did above) and scan for the keyword ‘nagios’. It’s possible it may still try to do things to which it’s being denied access to. You may even need to update your mynagios.pp SELinux module with extra entries found using audit2allow again. Consider also that it may be doing things you’re quite happy to leave the way it is. You don’t need to grant it access to absolutely everything, just want is necessary for it to operate.

Remember; if your project is compromised it will try to do all sorts of things it shouldn’t do and SELinux will be the barrier that will save your system.

Enable User Disk Quotas

Even if you’re running SELinux and have locked your system with auditing. A hacker can still try to bring your system down completely by filling it’s disk space until it’s full. This can cause other applications to catastrophically fail or stop behaving as they should which will is not cool at all.

By enabling user disk quota’s you can restrict the amount disk space imposed by a user (and even group level). Above, in the "Restricting SSH Access" points, I created a user called nuxref who i’d use as the entry point into my system. If you followed that piece of advice and significantly restricted remote access to your system you’re already halfway there. But… in the extremely unlikely circumstances that remote entry account gets compromised, you will want to be sure you keep the hackers options to a minimum.

Since I’ll only use that account to access the system and either check a few things or switch to the root user to make a change, I want to eliminate it’s ability to do much anything else. Most hackers start transferring all their hacking tools onto the system the second they gain access. It’s through these tools they can exploit more content. Other hackers might just want to completely fill your disk space causing your production data to crash.

An Example When You Might Want To Consider Disk Quotas:
Some cloud hosting services that provide you a bare bone virtual machine do not partition/carve out it’s disks in ways you’d have otherwise done differently. They do this primarily because they usually offer such small amounts of disk space (like 20-40GB) and it would be unfair of them to carve it in a way you might complain about. It’s better for them to just give your the entire space as one partition. But hey! When you pay for a very cheap hosting service; you take what you get. 🙂

Here is an example of what one of the virtual hosting providers I use did to my system when they gave it to me:

[root@node01 ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vda              20642428   1437052  18156800   8% /
none                    251228         0    251228   0% /dev/shm

In this example, /home (where users log into) and /tmp are not carved into their own partition. These directories are critical because all users usually have full read/write permissions here. If this were your production environment (and it is for many), a user could completely fill these unprotected directories until the file system was full. So in this example, Disk Quotas would be a very good idea!

Setting Disk Quotas Up
I will set up a assuming the file system I have to work with is identical to that displayed above (where I only have a ‘/’ partition) and a single user account that is accessible by SSHD. I’ll keep using the nuxref account to make things consistent.

Up until now I also gave you ‘one-liners’ to automate everything by simply copying and pasting from your browser to your command line. Well this one here will differ across systems, so it’s not really fair for me to give you this.

  1. First make sure the correct software is installed onto your system: 
    yum -y install quota
  2. Identify what partition needs to be updated. You need to open up your /etc/fstab file for this. I’m personally a vi fan, but use whatever editor your comforatble with. 
    # Here is a before snapshot of the /etc/fstab file before I edited it:
[root@node01 ~]# cat /etc/fstab             
LABEL=DOROOT       /               ext4    errors=remount-ro 0       1
none             /dev/shm      tmpfs   defaults                    0 0
  3. I want to adjust the ‘/’ partition (column 4); I need to update the line that already reads errors=remount-ro with errors=remount-ro,usrquota,grpquota. The fstab file will look like this for me when i’m finished: 
    # Here is an after snapshot of the /etc/fstab file after I edited it:
[root@node01 ~]# cat /etc/fstab 
LABEL=DOROOT       /               ext4    errors=remount-ro,usrquota,grpquota 0       1
none             /dev/shm      tmpfs   defaults                    0 0
  4. Now remount the ‘/’ filesystem (or whatever mount you chose to update in your /etc/fstab file) by typing the following: 
    mount -o remount /
  5. Now allow your system to scan your filesystem for files so it can begin tracking them: 
    quotacheck -avugm

    The step above could take hours depending on how busy your system is or the number of files that reside on the partition your scanning.

    You may see some output like this (don’t worry; nothing bad has happened) 🙂

    quotacheck: Scanning /dev/vda [/] done
quotacheck: Cannot stat old user quota file: No such file or directory
quotacheck: Cannot stat old group quota file: No such file or directory
quotacheck: Cannot stat old user quota file: No such file or directory
quotacheck: Cannot stat old group quota file: No such file or directory
quotacheck: Checked 4404 directories and 30017 files
quotacheck: Old file not found.
quotacheck: Old file not found.

    You may also see a warning like this:

    quotacheck: Your kernel probably supports journaled quota but you are not using it. Consider switching to journaled quota to avoid running quotacheck after an unclean shutdown.

    Journaling is a way of managing the transactions that are written and removed from your hard disk. It makes for a faster and more promising data recovery should your server ever suffers a hard crash (power outage or kernel crash). Journals sure do have their merits, but there are times when you don’t want them either. One reason is because your server is using a Solid State disk. These drives are SO much faster then traditional (mechanical) hardrives, but the trade off is they don’t like unnecessary writes. Disabling journaling is a way of prologging the life of these kind of drives.

    In a nutshell… if you’re getting this warning about journaled quota being disabled, it’s not a bad thing. In the example I’m using, the ‘/’ (ext4) partition is in fact residing on a Solid State hardrive, so I’m already fully aware of my scenario and know that the filesystem was formatted with out journaling enabled. So if it’s disabled already on your system too, think twice before enabling it; it is probably disabled for a reason and is completely safe to leave off (despite this warning).

  6. Now we can activate the quota system:

    quotaon -av

    You should see the following output (/dev/vda will be replaced with whatever device your currently watching quotas with):

    /dev/vda [/]: group quotas turned on
/dev/vda [/]: user quotas turned on
  7. Now you can look at the restrictions put in place:

    [root@node01 ~]# repquota -a
*** Report for user quotas on device /dev/vda
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 1212596       0       0          32284     0     0       
postfix   --      60       0       0             38     0     0       
nuxref    --      60       0       0             10     0     0 
apache    --      12       0       0              3     0     0       
postgres  --      16       0       0              4     0     0

    The quota are identified under the soft and hard columns which are all zero’s (0). This means there are no restrictions in place at all.

  8. We want to impost a restriction on the nuxref user in my case. I want to restrict this user to 10MB as there is no excuse why I should need more then that if I’m only using the account to check on things or switch to root. This is done using the command edquota username which will pop up an editor allow you to change these fields.

    # Edit the nuxref user's quota
edquota nuxref
# Adjusted both the soft and hard limits to 8 and 10 respectively.

[root@node01 ~]# repquota -a    
*** Report for user quotas on device /dev/vda
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 1212596       0       0          32284     0     0       
postfix   --      60       0       0             38     0     0       
nuxref    --      60    8000   10000             10     0     0 
apache    --      12       0       0              3     0     0       
postgres  --      16       0       0              4     0     0

    As you can see, the nuxref user is now restricted to 10 MB. If soft limit (set to 8MB in this example) is reached, an email will be sent to the user and for a ‘grace’ period (default is 6 days), the user will still be able to write more content to this directory. But after the grace period is reached the ‘soft’ limit is identical to the ‘hard’ limit and restricts further writing (until you clean up some space).

    It’s worth noting too that we could have acomplished the exact same effect (without using an editor) as above with the following one liner:

    # If you script the following; make sure you specify the correct device!
# /dev/vda is used below only because that follows inline with all my
# examples above.
setquota -u nuxref  8000 10000 0 0 /dev/vda

Disk Quotas Key Point If You Use Them:
I want to be clear about this: If you choose to use Disk Quotas, you only really need to lock down the accounts that ‘could’ be compromised. In my examples in this blog, I only have one account (nuxref). It’s not necessary to lock down system accounts like apache, postgres, mysql, etc. NEVER lock down the root user!. Most of you may not even need to do this step; It truly is an extreme (and in most cases unnecessary) precautionary step that only ‘some’ should take.

Heartbleed Security Exploit

This is probably one of the biggest security exploits that has surfaced in the past few years that can compromise many systems (and potentially has been for years). This includes systems such as CentOS 6.5 (or less) allowing attackers to access random (64K) chunks of your RAM (memory) at a time (which is almost never encrypted). This can allow them to extract a lot of sensitive information that they shouldn’t have otherwise been granted access to. If you’ve installed a newer version of CentOS (or Red Hat) than v6.5 you are most likely okay. But with that all said: Make sure your version of OpenSSL is at least 1.0.1e-16!

You can check your version by typing:

# Check the details of your openssl:
rpm -qi openssl
# The output should read this version (at least):
#
Name        : openssl                      Relocations: (not relocatable)
Version     : 1.0.1e                            Vendor: CentOS
Release     : 16.el6_5.7                    Build Date: Mon 07 Apr 2014 10:43:19 PM EDT
# ....

If your version of openssl is not satisfactory, then you should update it immediately to keep your system secure! Download it from the CentOS repositories directly, or use yum:

# Get the latest version of openssl
yum update -y openssl

The website heartbleed.com does a fantastic job explaining the details on this exploit if you are interested. The Common Vulnerabilities and Exposures is defined here: CVE-2014-0160.

Credit

This blog took me a very long time to put together and test! 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

A lot of what I wrote here was accumulated knowledge over time. I can’t recall where all my sources came from and for that I’m sorry. This blog is more of a brain dump along content I keep in a personal Wiki containing information I’ve been meaning to share with everyone.

Here are some great links that may help you understand some topics discussed here a bit better though:

Linux HOWTO

Configuring and Installing Nagios Core 4 on CentOS 6

7 Comments

Introduction

Nagios is a powerful tool that allows you to monitor just about anything. It’s so easy to even take existing legacy system and adapt it to work with Nagios. When I came across kingkiwix and his blog here I wanted to repackage the content in a more user-friendly way for sharing. I wanted a solution that didn’t require me to pull in a bunch of development libraries and compilers. I also wanted a solution that I could re-use on other systems through a version controlled and packaged interface.

Those running CentOS 7.x might be interested in this new blog entry: Nagios Core 4.x Setup for CentOS 7.x.

RPM Solution

RPMs provide a version control and an automated set of scripts to configure the system how I want it. The beauty of them is that if you disagree with
something the tool you’re packaging does, you can feed RPMs patch files to accommodate it without obstructing the original authors intention.

Now I won’t lie and claim I wrote these SPEC files from scratch because I certainly didn’t. I took the stock ones that ship with both products (both Nagios and Nagios-Plugins) and modified them significantly to accommodate and satisfy my compulsive needs. 🙂

My needs required a bit more automation in the setup as well as including:

  • The use of nagiocmd user group.
  • A /etc/nagios/conf.d directory to behave similar to how Apache works. I want to be able to drop configuration files into here and just have it work without re-adjusting configuration files.
  • Alerting Apache on new updates/installs so just installing the package alone is all you need to do.
  • Nagios Plugins should work right away once they are installed.
  • Nagios Plugins and permissions should adapt to the new nagiocmd user and place in a common directory Nagios was already configured to look in.
  • Nagios Plugins has to many dependencies; I wanted to break this up into separate packages for those who needed them. For example, I don’t use MySQL at all; so why should I need the MySQL Libraries installed on my system just to use Nagios Plugins.
  • Nagios group permissions added to /etc/nagios directory for people using third party management applications. Just add any third party app to the Nagios group and they’ll be able to manage your configuration too: 
    # substitute <3rdpartyid> for the actual group/id belonging
# to the software in question.
usermod -a -G nagios <3rdpartyid>

Stop Babbling, Just Give Me All Your Hard Work

Of course here it is:

At a minimum you need to install both Nagios Core (v4.2.0) and it’s accompanied Nagios Plugins (v1.5) package.

For those who are interested, here is a quick direct link to my additions to the building environment and deployment:

I Installed the Packages, Now What?

The RPMs take care of just about everything for you, so there isn’t really much to do at this point.

  • Make sure Apache is running and if it isn’t start it: 
    # the following way is a harmless way of checking if Apache is
# running and starting it if it wasn't (requires root)
service httpd status || service httpd start

# If it wasn't started in the above command, you may want to
# consider having it start up each time you reboot your machine
# through the following command:
chkconfig httpd --levels 345 on
  • Start Nagios 
    # Startup Nagios (requires root)
service nagios start

# Consider having Nagios (Backend) start up each time you reboot
# your machine through the following command:
chkconfig nagios --levels 345 on

# You'll also want to set up a nagiosadmin password
# The below will set you up with one using the pass of 'password'
sudo htpasswd -cb /etc/nagios/htpasswd.users nagiosadmin password

Visiting http://localhost/nagios/ should look similar to this if you followed the steps correctly
Visiting http://localhost/nagios/ should look similar to this if you followed the steps correctly
Yes, that’s right… you’re done! You can access your Nagios Web Interface by visiting http://localhost/nagios. How you configure your system further is beyond the scope of this tutorial/blog. My goal was just to get you started with an out of the box working Nagios solution :).

If your not already familiar with Nagios, you may want to read the documentation so you can monitor more then just the 8 example checks it sets up for you out of the box. There are also some great web configuration tools you can check out as well here.

Package Information

  • Software installs to: /usr/share/nagios
  • Plugins install to: /usr/lib64/nagios/plugins. Keep in mind I packaged everything in such a way that compiling it for 32-bit will work fine. In which case you’ll find plugins installed to: /usr/lib/nagios/plugins
  • Website is accessible at: http://localhost/nagios/ out of the box, but you can adjust it’s web configuration by adjusting /etc/httpd/conf.d/nagios.conf to your likings.
  • Nagios Core 4 configuration file can be found at: /etc/nagios/nagios.cfg and a newly added /etc/nagios/conf.d/ directory has been added to make some things easier to add/remove later. 
    • # SELinux Users may wish to turn this flag on if they intend to allow it
# to call content as root (using sudo) which it must do for some status checks.
setsebool -P nagios_run_sudo on

    I want to repackage this myself

    All of my blogs provide a way to build everything from scratch yourself for those who don’t want to just download the binary packages and roll with them. I use mock for everything I build so I don’t need to haul in development packages into my native environment. You’ll need to make sure mock is setup and configured properly first for yourself:

    # Install 'mock' into your environment if you don't have it already.
# This step will require you to be the superuser (root) in your native
# environment.
yum install -y mock

# Grant your normal every day user account access to the mock group
# This step will also require you to be the root user.
usermod -a -G mock YourNonRootUsername

    At this point it’s safe to change from the ‘root‘ user back to the user account you granted the mock group privileges to in the step above. We won’t need the root user again until the end of this tutorial when we install our built RPM.

    # Perhaps make a directory and work within it so it's easy to find
# everything later
mkdir nagiosbuild
cd nagiosbuild
###
# Now we want to download all the requirements we need to build
###
# Nagios Core 4
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-4.2.0.tar.gz
# Nagios Plugins v1.5
wget https://www.nagios-plugins.org/download/nagios-plugins-1.5.tar.gz
# Customize Nagios Spec Files
wget http://repo.nuxref.com/pub/nuxref/nagios/nagios.spec
# Customize Nagios Plugin Spec Files
wget http://repo.nuxref.com/pub/nuxref/nagios/nagios-plugins.spec
# Nagios Patch to enable a conf.d directory
wget http://repo.nuxref.com/pub/nuxref/nagios/nagios.conf.d.patch
# Nagios Patch to fix accumulating files in /tmp/*
wget http://repo.nuxref.com/pub/nuxref/nagios/configtest.tmp.patch
# Nagios Plugin Patch to include some sample configurations and
# setup Nagios to work out of the box
wget http://repo.nuxref.com/pub/nuxref/nagios/add.sample.command.cfg.patch

###
# Prepare our mock environment
###
# Initialize Mock Environment
mock -v -r epel-6-x86_64 --init

# Copy in our downloaded content:
mock -v -r epel-6-x86_64 --copyin nagios-4.2.0.tar.gz 
   nagios-plugins-1.5.tar.gz 
   nagios.conf.d.patch 
   add.sample.command.cfg.patch 
   onfigtest.tmp.patch 
   /builddir/build/SOURCES

mock -v -r epel-6-x86_64 --copyin nagios.spec nagios-plugins.spec 
   /builddir/build/SPECS

# Install Dependencies
mock -v -r epel-6-x86_64 install gd-devel zlib-devel 
   libpng-devel libjpeg-devel doxygen gperf perl-devel net-snmp-devel

# Install Plugin Dependencies
mock -v -r epel-6-x86_64 install bind-utils mysql-devel net-snmp-utils 
               postgresql-devel ntp openldap-devel openssh-clients 
               samba-client /usr/bin/mailq

###
# Build Stage
###
# Shell into our enviroment
mock -v -r epel-6-x86_64 --shell

# Change to our build directory
cd builddir/build

# Build our RPMS
rpmbuild -ba SPECS/nagios.spec
rpmbuild -ba SPECS/nagios-plugins.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

###
# Save our content that we built in the mock environment
###
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/SRPMS/nagios-4.2.0-2.el6.src.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/SRPMS/nagios-plugins-1.5-5.el6.src.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-plugins-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-plugins-mysql-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-plugins-pgsql-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-plugins-ldap-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-ntp-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-snmp-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-samba-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-plugins-debuginfo-1.5-5.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-4.2.0-2.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-contrib-4.2.0-2.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-devel-4.2.0-2.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-selinux-4.2.0-2.el6.x86_64.rpm .
mock -v -r epel-6-x86_64 --copyout \
   /builddir/build/RPMS/nagios-debuginfo-4.2.0-2.el6.x86_64.rpm .

# *Note that all the commands that interact with mock I pass in 
# the -v which outputs a lot of verbose information. You don't
# have to supply it; but I like to see what is going on at times.

# **Note: You may receive this warning when calling the '--copyout'
# above:
# WARNING: unable to delete selinux filesystems 
#    (/tmp/mock-selinux-plugin.??????): #
#    [Errno 1] Operation not permitted: '/tmp/mock-selinux-plugin.??????'
#
# This is totally okay; and is safe to ignore, the action you called
# still worked perfectly; so don't panic :)

    Considerations

    If you take Nagios seriously, you will really want to consider expanding it to support one (or all) of the following addons:

    • NRPE - Nagios Remote Plugin Executor
      NRPE – Nagios Remote Plugin Executor
      NRPE – Nagios Remote Plugin Executor
      NRPE is an addon that allows you to execute plugins on remote Linux/Unix hosts. This is useful if you need to monitor local resources/attributes like disk usage, CPU load, memory usage, etc. on a remote host. Similar functionality can be accomplished by using the check_by_ssh plugin, although it can impose a higher CPU load on the monitoring machine – especially if you are monitoring hundreds or thousands of hosts.
    • NSCA - Nagios Service Check Acceptor
      NSCA – Nagios Service Check Acceptor
      NSCA – Nagios Service Check Acceptor
      NSCA is an addon that allows you to send passive check results from remote Linux/Unix hosts to the Nagios daemon running on the monitoring server. This is very useful in distributed and redundant/failover monitoring setups.

    I’m considering packaging these as well to conform with the packages I’ve already provided here, but I’ll do that in another blog some other time if there ends up being a demand for it 🙂.

    Dec 8th, 2013 Update: I ended up creating this blog to extend this one: Configuring and Installing NRPE and NSCA into Nagios Core 4 on CentOS 6.

    Credit

    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 referenced the following resources to make this blog possible:

    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.