Securing Dokuwiki with nginx

After migrating a server from Apache2.4 to nginx a Dokuwiki install was complaining about the following on the admin page:
Dokuwiki security error with nginx
Dokuwiki security error with nginx
  Previously .htaccess files were controlling access, which aren’t used by nginx. You can test your Dokuwiki install’s access by attempting to visit the following url:
  If you can see any content there, you need to fix your permissions. We fixed this by adding the following to the site’s nginx config file (e.g. /etc/nginx/sites-available/sitename):  
location ~ ^/(data|conf|bin|inc) { deny all; }
  …in the same section as the other “location” stanzas, then restarted nginx (whether the latter is necessary or not I don’t know, force of habit).

Thunderbird and Google Apps or Gmail – wrong password message despite correct password being entered

This is a frustrating issue – you have youreslf a shiny new Gmail or Google apps account, but for some reason when you try to add the account to Thunderbird it complains about your password being incorrect:  
Configuration could not be verified – is the user name or password wrong?
  After double checking that the password is indeed correct, the most common cause we have found for this is that IMAP is disabled in your gmail settings. Log into your gmail via a web browser and click on the gear in the top right, then select:  
Settings -> Forwarding and Pop/IMAP
  Once you are in the Forwarding and Pop/IMAP tab, scroll down until you see:
IMAP Access
  Hopefully the radio button for Disable IMAP is selected. If so, select “Enable IMAP”, save your settings and try again. Hopefully that ends your frustrating login attempts!

ZFS on Linux: Zpool import failed

We upgraded a Proxmox box today which was running ZFS and ran into this rather scary looking error:  
zpool: ../../lib/libzfs/libzfs_import.c:356: Assertion `nvlist_lookup_uint64(zhp->zpool_config, ZPOOL_CONFIG_POOL_GUID, &theguid) == 0′ failed.
  Zpools would not import and zpool status did not work. Resolved (so far, anyhow, still testing) by running:  
apt-get install zfsutils
  Another good reason to have test environments…

Proxmox 3.2: Enabling NFS on a container (CT) VM

  If you’re trying to figure out why you are getting NFS errors despite having NFS set up properly on the host machine and client VM, this may be the answer. With the VM powered off, run at the Proxmox terminal:  
vzctl set [VM ID] --features "nfs:on" --save
  The next time the VM is powered up NFS should be enabled and you should be able to mount shares correctly. An example:  
vzctl set 104 --features "nfs:on" --save

Rsync error when connecting to CentOS: rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

  We helped rebuild a backup VM which receives data over rsync today; the first rsync attempt failed with the vague error message:  
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
  The problem ended up being that the rsync package was not installed. A simple:  
yum install rsync -y
  …fixed the problem and shortly the backups were back to normal.

Mediawiki 403 forbidden errors after upgrading to Ubuntu 13.10

  A customer upgraded from 13.04 to 13.10 and their internal wiki was broken afterwards; for a simple Apache install where the wiki was installed at the web root and all access was via the LAN (thus they were happy with not restricting the access), the fix was to add:  
<Location /> Require all granted </Location>
  towards the bottom of:  
…just above the last line, which should be </VirtualHost>. Restart apache with:  
service apache2 restart
  After that you should be able to refresh and see your wiki as before.

New CentOS WordPress install: Error 500

  Was asked to troubleshoot a client’s installation technique for WordPress on CentOS 6.x yesterday; they were receiving an Error 500 when they tried to access index.php for the first time. Checking the Apache logs showed:  
SoftException in Application.cpp:431: Mismatch between target GID (522) and GID (65531) of file “/home/andrea/public_html/index.php” Premature end of script headers: index.php
  What was happening was that the client was un-tarballing the latest.tar.gz file as root and then changing the ownership of the file with the following:  
chown -R [user] *
  Changing that command to:  
chown -R [user]:[usergroup] *  
e.g. here:  
chown -R andrea:andrea *
  fixed that error. By not specifying the new group there was an ownership mismatch where the system expected one group but got another. There are many¬† causes for an Error 500 – it’s a good habit to check the Apache logs first for pointers as to where to start troubleshooting.

New Mediawiki install produces error “Fatal exception of type MWException”

  Saw this on a new Mediawiki install where all of the optional extensions were selected, LocalSettings.php had been uploaded to the server and that’s as far as it would go.   To fix, open up LocalSettings.php and comment out the line:  
require_once( “$IP/extensions/LocalisationUpdate/LocalisationUpdate.php” );
  You should now be able to refresh the main page and start using your wiki.