Movable Type - DataSource error

Hi. I'm in the process of moving hosts, and I plan to set up Movable Type and make sure it's all working before I transfer my DNS settings.

So I've managed to install MT using the very helpful directions at http://wombatnation.com/misc/installMTDreamHost.html.

However, when I attempted to run mt-load.cgi, I got the following error: Your DataSource directory ('./db') does not exist. So I went into the mt.cfg file, and the line read as "DataSource ./db" - there were no # symbols preceding this line, which means it's uncommented, right?

First I checked the mySQL database settings I had in DreamHost and matched those against what was in mt.cfg. That was fine. Next, I realized that when I uploaded my edited mt.cfg, I did it in binary instead of ASCII mode. So I re-uploaded in ASCII mode. (And then I forced myself to try emacs so I could just edit on the server.)

After hunting around here in the forums and in the official MT instructions and on the web, I edited the DataSource line to reflect the path to my directory, so that the line read as the following: DataSource /home/myusername/mydomain.com/mt.

I ran mt-load.cgi, and the installation worked. But here's my question: I was trying to set up MT with mySQL as opposed to Berkeley DB support, and it appears that editing the DataSource line is what you're supposed to do IF you're going to use the Berkeley DB support. Am I understanding this correctly, that I'm NOT supposed to edit the DataSource line if I'm using mySQL instead of Berkeley?

So where did I go wrong? Should I re-install from scratch?

Also, a smaller question. I'd like my blog to be at mydomain.com, not mydomain.com/blog as suggested by the instructions. According to the installation instructions, I really should set permissions to 755 for the root directory for my blog, which in this case is the mydomain.com folder set up for me when I signed up with DreamHost. When I tried to do that, I had problems accessing it in Putty. Currently that folder is set to 777 but I'm not sure how to resolve this.

Ok, I realized belatedly that I needed to register, so I've done that and now I'm replying to my own post. Here's something I realized when I was editing mt.cfg.

By default, the DataSource line was uncommented, so the full line when I first opened up mt.cfg for editing read as: DataSource ./db.

Should I edit the line to read as: # DataSource ./db instead of what I ended up using, which was: DataSource /home/myusername/mydomain.com/mt?

I left the Datasource entry uncommented and unchanged in mt.cfg. That is:

DataSource ./db

If something is wrong with the database configuration, MT fails to connect to a MySQL datbase using the info provided and falls back on trying to use BerkeleyDB. With the default value above, it will also fail. By correcting the value, you ended up getting MT to use BerkeleyDB, as you surmised.

Commenting out DataSource or leaving it with an incorrect value effectively produces the same result. MT will not be able to use Berkeley DB if MySQL fails.

My best suggestion is to try to connect to the database using PHPMyAdmin. My MT tutorial provides instructions for doing this. Try to copy and paste and paste the exact values from your mt.cfg file. The database connection info is case sensitive.

As for the permissions problem, is it possible you are connecting via ssh as a different user than the owner of the directory containing your website?

When you are in the directory containing the website (i.e., you are in the directory that contains the domainname.com directory), do an "ls -l" at a shell prompt. You should see something like:

$ ls -l
...
drwxr-xr-x 27 username groupid 4096 Nov 7 23:15 domainname.com
...

The name in the third column is the username of the owner of the directory. In the first column you can see the permissions, drwxr-xr-x. The d means this is a directory. The next three characters tell me that the owner has read, write, and execute permission for this directory. In this context, execute means I can cd into the directory.

The next three characters are the permissions for all other users in the owner's group. The fourth column has a groupid. Any other user who is in the same group as the owner of this directory has the permissions specified by the middle three characters.

The final three characters represent the permissions for all other users on that server.

So, after this long-winded tutorial, the symptoms you have described suggest to me that you are connecting via ssh as a user other than the owner, and are thus unable to write files when the permissions are 755. If you want to have full control, you will need to either connect as the owner of the directory, or leave rwx permissions set for the group (assuming, of course, the username you are using is in the same group as the owner).

Robert
http://www.wombatnation.com/

Thank you very much, Robert, for both answers.

I realized that I made a very simple, very literal (and very embarrassing) mistake, which I'll share for the sake of perhaps sparing someone the same confusion. The problem has to do with the fact that I haven't yet transferred my domain name from the old host to DreamHost.

When I created the MySQL hostname, it was in the format "mysql.domainname.com" - which would be fine, IF I had already transferred my DNS. Since I haven't done that yet, I should have created the hostname "mysql.domainname.dreamhost.com". This is because I initially created a DH sub-domain, "domainname.dreamhost.com", to use in the meantime. So when I ran mt-load.cgi, it's not surprising that I got the error of "Unknown MySQL Server Host..."

So I created a different database (different user, password) and the correct MySQL hostname "mysql.domainname.dreamhost.com". Once I updated mt.cfg to reflect this information, I was able to run mt-load.cgi and install MT successfully.

FYI, you can also attach multiple mysql hostnames to a single database.

Temporarily, you can also query our authoritative nameservers for the right IP to use and use that - just make sure you switch to using the hostname when you transfer the domain.

Oh, ok. So I didn't need to create another database to set up the mysql hostname that I needed. Will definitely make note of that. Thanks!