Wordpress is a free and open source content management system that is widely popular. This page will provide you with detailed instructions on how to install Wordpress using DomTool and AFS permissions.
This will guide you through downloading the latest stable version via Subversion, hardening permissions in the filesystem, and making a Domtool entry for the site.
Contents
1. Get the Source
If you have the OpenAFS client configured, you can set up Wordpress on your local system for the most part. The setup can (naturally) be performed on our shell server as well.
- Navigate to the directory you where want to host Wordpress. This can be anywhere in your home directory, but should not be in public_html. Creating a directory to store wordpress installations is good practice to keep your home directory organized.
- Now we will set the initial file permissions for the Wordpress root directory. In a moment, we will be using Subversion to create several folders and files. In AFS, new folders inherit the permissions of the parent folder. So by setting file permissions early, we can save ourselves some work later.
- Navigate to the directory where you will install Wordpress and execute the following:
fsr setacl . system:anyuser none fsr sa . $USER.daemon rlk
The first command makes it so that no one that you do not allow (except administrators) may access your Wordpress directory. The second command limits the privileges that the server software have over the directory to just reading, listing files, and executing code.
Follow the instructions for installing WordPress using Subversion. You will probably want to track the stable version rather than trunk.
svn co https://core.svn.wordpress.org/tags/$VERSION .
- If you want to be able to upload files, you need to set some permissions:
mkdir wp-content/uploads fs sa wp-content/uploads $USER.daemon write
2. Configure Wordpress
Using the documentation on DomTool/Examples#WordPress, add wordpress to a location on your site. This handles everything that the htaccess file would have done, and also prevents anyone from accessing the .svn directories.
Create a MySQL database, and configure accessing your database according to the Wordpress instructions. In Hcoop.net your MySQL database host name is just mysql.
You will also need to set the cookie salts in wp-config.php. Just visit https://api.wordpress.org/secret-key/1.1/salt/ and copy the result over the same part in wp-config.php
# in wp-config.php define('DB_NAME', '$USER_$DB'); define('DB_USER', '$USER'); define('DB_PASSWORD', 'XXXXX your mysql password XXXXX'); define('DB_HOST', 'mysql'); # visit https://api.wordpress.org/secret-key/1.1/salt/ to generate cookie salts, and copy/paste result over: define('AUTH_KEY', 'put your unique phrase here'); define('SECURE_AUTH_KEY', 'put your unique phrase here'); define('LOGGED_IN_KEY', 'put your unique phrase here'); define('NONCE_KEY', 'put your unique phrase here'); define('AUTH_SALT', 'put your unique phrase here'); define('SECURE_AUTH_SALT', 'put your unique phrase here'); define('LOGGED_IN_SALT', 'put your unique phrase here'); define('NONCE_SALT', 'put your unique phrase here');
Visit $WEBLOG_URL/wp-admin/install.php to complete the installation process
Run dbtool mysql grant $DATABASE for the database you created to grant drop and delete permissions
You should now have a working weblog.
3. Enabling the Plugin Manager
To use the plugin manager you have to allow your daemon user to write to the wp-content directory in your installation.
fsr sa wp-content/ $USER.daemon write
The way Wordpress tests if it can directly write files is incompatible with openafs1, so you'll need to force it to directly write the file system by adding a line to your wp-config.php:
define('FS_METHOD', 'direct');
4. Tips
4.1. Using Jetpack Without A Wordpress.com Account
You can use many of the features of Jetpack without a wordpress.com account by enable development mode in your wp-config.php:
define( 'JETPACK_DEV_DEBUG', true);
CategoryMemberManual CategoryMemberManual
It creates a file and then check that the UID is the same as the current process; at HCoop, this is not true since the file owner will be your daemon user which has a different UID. The owner UID check is pointless, and just makes our lives harder (1)