Informatics Blog Service


The blog.inf service runs on blogvm.inf, currently on girassol in the Forum (confirm this location with "kvmtool --name blogvm locate"). It should need little or no detailed attention on a daily basis. If the service is running normally, it can be monitored and administered from the Network Admin pages ( The services unit members, plus a few others have "super admin" access, see later.

The service uses WordPress (there is a wordpress.h header, but this refers to an outdated version of WordPress - the current blogvm configuration is all in the profile), which uses MySQL to store the blog postings and configuration information. The MySQL database can be accessed separately, but this is not recommended (unless WordPress is horribly confused, or passwords need to be manually reset).

Things To Check

There is no WordPress component. If the blog service is unresponsive, check the status of apacheconf on blogvm and restart if necessary. There are also WordPress-specific apache logs (apacheconf.wordpress and apacheconf.wordpress.errs in /var/lcfg/log; also modsec_audit.log in /var/log/httpd), which might yield helpful information. It is also worth checking that the cosign component is correctly configured.

Additional functionality is provided by Plugins - check the "Plugins" admin page, and also check the underlying files, which should be in /usr/share/wordpress/wp-content/plugins, in case something's happened at the filesystem level. On blogvm.inf, most plugins are provided by separate RPMs.

Current Configuration

The blog.inf service hosts several discrete blogs, each separately administered by their owner and maintainer. The blog admin user (or a user with admin role) for a blog has control over user access for that blog. There are also one or more super-admin users for the blog service as a whole, who can change settings for any or all individual blogs. The "Super Admin" users are currently:

  • Craig
  • Gordon
  • Neil
  • Ross
  • Stephen

As currently configured, blog.inf runs as a CoSign-enabled service and non-SSL requests are redirected to the equivalent SSL URL. DICE users can have a WordPress blog account created automatically - but this is configured on a per-blog basis using the HTTP Authentication plugin.

Posts and comments are administered from separate pages, and can be approved, deleted, marked as spam by the admin user - select the relevant option, "Posts" (pin icon) or "Comments" (speech bubble icon), from the left-hand menu (note that only option icons, and not option names, may be displayed if the web browser is too narrow).

Additional functionality can be added via the "Plugins" (plug icon) menu. These need to be added by a Super Admin user, but can then be enabled/disabled by individual blog admins. Once a plugin is enabled, an additional option/icon may appear on the left-hand side (as is the case for "Better WordPress reCAPTCHA"), or just have a configuration option in "Settings" (as is the case for "HTTP Authentication").

Usual apache config is in /etc/httpd/ , and the file component generates some wordpress.conf files in /etc/httpd/conf.d

As on this service, WordPress and the plugins come via RPM, the site is rooted in the default location of /usr/share/wordpress/, however there are symlinks out of that location to other places, most notably wp-content/blogs.dir -> /etc/wordpress/blogs.dir, where blog related files are stored.


The directories:

  • /var/lib/wordpress
  • /usr/share/wordpress
  • /etc/wordpress

are mirrored nightly (currently by bulleid) and then to tape. There is a cron that does a mysql dump of the DB into /var/lib/wordpress, which may be needed for disaster recovery.

From Scratch

The creation of a WordPress server consists of identifying a suitable host, and then:

  • install web-server RPMs (if not already installed)
  • install WordPress RPMs
  • configure WordPress VHost
  • configure WP (MySQL) database
  • configure WordPress

Neil has made some notes on installation, see his WordPressNotes. In addition to these - if CoSign is to be used - the HTTP Authentication plugin must be enabled (using the "HTTP Authentication" option from the "Settings" menu, and selecting "Automatically create accounts?").

Disaster Recovery

If the VM hosting blog.inf dies, and can't be recovered, then the simplest thing to do is recreate the VM with the same profile, and restore the data from backups.

Once you have the replacement VM installed

  • Stop apache and mysql.
om apacheconf stop
om mysql stop
  • check there are no processes left running.
  • restore /etc/wordpress, /var/lib/wordpress/, /var/lib/mysql
  • check the symlinks in /usr/share/wordpress for wp-config.php and wp-content/blogs.dir are working.
  • start mysql om mysql start and check it is working/looks sane
[blogvm]root: echo show databases | om mysql runcommand
[OK] mysql: runcommand
  • If there are errors or the above doesn't work, you'll have to fix that first. Possibly restoring the data from the last dump in /var/lib/wordpress/data.dump
  • start apache om apacheconf start

Other Possible Problems

Whilst not actually a problem, it may be useful to understand how a person would grant access to their blog for another person (who has a DICE or iFriend account). There is a miniscule amount of documentation about this on the pages, and Neil wrote a blog post on the same topic.

Not sure if this is really a problem either, but it might be necessary to update WordPress if a security update comes out.

-- RogerBurroughes - 24 Mar 2014 -- NeilBrown - 06 Mar 2019

Topic revision: r7 - 06 Mar 2019 - 15:36:13 - NeilBrown
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies