:: TheOneAndTheOnly.com – Andrew Buckman ::

I was recently setting up a subdomain for a URL pointing at a shared IP.  The domain itself already had DNS set up for all subdomains to go to the IP, but nothing was being done with them on the server.  In a moment of curiosity, I checked out the subdomain’s URL before I set it up on the server and much to my dismay, it pulled up the primary website set up on that IP, a completely different domain than this subdomain was going on.  This is obviously not good because of duplicate content issues with the search engines, I certainly don’t want an entire copy of my site reachable on an unlimited number of subdomains on other domains.  To combat this, I’ve added an Apache Rewrite directive to my .htaccess file that rewrites anything not on the correct domain over to the proper one using a permanent redirect.

RewriteCond %{HTTP_HOST} !theoneandtheonly\.com
RewriteRule .* http://www.theoneandtheonly.com/ [R=301,L]

Obviously, replace theoneandtheonly.com with your domain of choice.  Please be sure to put this after any other subdomain rewriting rules you might be using.  I don’t intentionally send subdomains to my main URL, if you do, you may need to tweak this a bit.  Also I opted to drop any path information on the rewritten URL, if you’d prefer passing that along, use the version below instead.

RewriteCond %{HTTP_HOST} !theoneandtheonly\.com
RewriteRule ^(.*)$ http://www.theoneandtheonly.com/$1 [R=301,L]

For the record, I encountered this problem on a server running Plesk 8.2.1, it may or may not be an issue under other setups.

So it seems there’s something wrong with Urchin 5 that is preventing my web stats from being compiled out of the logs files and into Urchin’s reporting interface. This began happening a year after I switched to the current server (running Plesk 7.5) and I noticed it on a few more important domains and found a fix at that time. Meanwhile I wrote myself a post-it note to go back and fix it on the rest of the domains, which of course I never did. Today I was curious about some stats for one of the domains I hadn’t fixed and thankfully was still able to find my note. I’ve decided to blog the solution so that I don’t have to worry about losing that note any longer and hopefully it will help someone else in the future as well.

If you try processing your log by clicking the “Run Now” button in Urchin Admin and see the following message come up, these instructions should help with your problem.
WARNING: (7063-54-63) Unable to open database for writing since it has been archived

The official solution to this problem exists on the Urchin Help site (now owned by google) at this location:
http://www.google.com/support/urchin45/bin/answer.py?answer=28527&topic=7393

My more detailed walkthrough follows…

The problem has to do with the archiving feature on a per domain basis. If you login to the Urchin Admin interface and configure the profile for that domain, there is a Storage/DB tab. On the tab you’ll see “Archive DB Options” with options for on/off and a timeframe for archiving if you leave it on. Change the setting for “Archive DB” to off and click “Update” to save your change.

The second half of the fix is a bit trickier and will require shell access to your server with an appropriate permissions level that grants you access to urchin’s installation directory. I logged in via ssh and switched to the superuser account to perform the following tasks (obviously you do so at your own risk, remember when you’re the superuser you have the power to break many things you don’t want to break). First, find where urchin is storing its reports for the domain you’re fixing (/usr/local/urchin/data/reports/theoneandtheonly.com/ for this domain). Change to that directory and look at the contents. You should see a variety of zip files named with the following format: YYYYMM-archive.zip. You should unzip these files to restore the data from the archives and remove the archive.zip files after they’ve been unzipped. This is important, you MUST remove the archive files, or at least move them to another directory so Urchin doesn’t see them.

UPDATE: By request, here is a list of the commands I ran for step 2…
cd /usr/local/urchin/data/reports/theoneandtheonly.com/
unzip *-archive.zip
mkdir archive-backup
mv *-archive.zip archive-backup


After both steps above are complete, go back to your Urchin Admin interface and run the stats report. You should see it processing your log files again and your missing data should fill in. Depending on the log file rotation schedule for your webserver you may or may not have gaps. If you keep backups on your server of all the logs, you should be able to reconfigure urchin to process the old files if you don’t have it setup that it does so already.

Another quick How-To for Plesk 7.5 Reloaded for Linux. I was setting up a Web User account and realized there is no option to grant SSH access in the control panel when doing so. Obviously that’s normally a good thing, but with scp-only as the shell to allow SFTP/SCP without granting actual SSH access, I wanted to assign it to the web users. Fortunately it’s quick and painless to do so on the command line via SSH.

First, create the web user and note the name of the account. We’ll use paris for our example.

Now, login via SSH, su to become root, and enter the line below:
usermod -s/usr/libexec/openssh/sftp-server paris

That should change the shell for the user to scp-only. If you haven’t already installed scp-only, check out my other post on the subject: HOW-TO: SFTP on Plesk 7.5 Reloaded for Linux.

As I’m transitioning from the current Ensim 3.1 server to a new server running Red Hat Enterprise Linux 3ES with Plesk 7.5 Reloaded, one very major issue came up. I refuse to use plain FTP for file transfers, always using SFTP, yet it wasn’t working on the new server. Not cool. Turns out you need SSH enabled on the account thereby granting the user shell access. Now I need multiple SFTP accounts, but I have no desire for them all to have shell access as well. After a bit of research I came across scponly which acts like a shell, yet restricts the user to using it only for SFTP/SCP, no command prompt at all. Plesk conveniently has a selection box for you to choose a shell when granting SSH access to user accounts, so after getting scponly installed, it’s now a piece of cake to grant SFTP/SCP access without giving shell accounts. Instructions after the jump for anyone looking to do the same.
(more…)