Change the SSH Port

SSH is usually on port 22 and attackers know this so they will attack the server on port 22. Change the port to anything else and they will need to attack every port to find SSH.

To change the port edit /etc/ssh/sshd_config and find the line:

#Port 22

And remove the # and change the port number to something else in the 10,000s.

Port 13574

Save the file, exit, and reload the SSH daemon.

/etc/init.d/sshd restart

Now, when you ssh into the server you’ll need to specify the port.

ssh <username>@<domain> -p 13574

Special Note: If you’re using SFTP for the system user make sure you change the port in your FTP program as well.

Set Up a Second Root User and Deactivate Primary Root Access

MT explains how to do this and it’s a great tip. They use the user name ‘admin’ in their example. Be sure to use a different name.

Add An AllowUsers Line to the SSH Config File

If you have a limited number of users who should have access to SSH edit the /etc/ssh/sshd_config file and add the AllowUsers directive:

AllowUsers <username1> <username2> <etc>

You can have multiple names by separating them with a space. I typically add the alternative root user I created from the trick above as well as the SFTP system user I create.

Once again, save the file and reboot the SSH daemon.

/etc/init.d/sshd restart

Don’t you feel more secure already?

Before we get to that though, first activate SFTP for the ftp user following MT’s wiki advice. And yes, I realize this is a post about activating SSH for the FTP user but it all shakes out the same because you can’t have SFTP without SSH being activated and the SFTP wiki post is over long. When you enable SFTP the way MT suggests you select a shell for the ftp user. Any shell will do because we will replace it with scponly later.

Once the ftp user’s changes have been saved, access the server with SFTP and then with FTP to convince yourself that they both work. You can also try SSHing into the server to prove that the ftp user can now access the server from the command line.

To lock down the ftp user you need to follow the steps in Govindarajan’s blog post. The steps are, briefly, install RPM Forge, install scponly via yum, and then edit /etc/passwd to reassign the ftp user’s shell.

rpm -ivh http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

yum install scponly

vi /etc/passwd

In vi, scroll down to the line for the ftp user. Enter editing mode and change the shell, say it’s /bin/bash, to /usr/bin/scponly. Save and exit vi.

Now attempt to sign back into the server with the ftp user using FTP. It won’t work. Try with SFTP, works great. Try SSH. Not only doesn’t it work, it hangs the attempt and provides no feedback to the attacker.

To recap, now you have a transfer account that uses SFTP, can’t use FTP, and is locked out of access SSH via the command line. Wonderful.

I’m happy to report that the problem has been fixed! Shortly after my blog post I was contacted by Dain Kennison at MT and he thanked me for pointing out the issue and said he would get it fixed. Just this evening I was signing up another client with MT (my first since the blog post) and the checkout issues have been cleared up.

First, the three step activation process have been made clearer:

Step 3 used to say ‘Confirmation’ and I think the new ‘Done’ is a more definitive statement. Confirmation can mean a variety of things, done just means done.

The second improvement, and the one I think makes all the difference, is that the button at the end of step 2 no longer says ‘Continue Order’, which is very ambiguous, but now says ‘Complete Order’, which is definitive.

These two small changes make a world of difference in orientating users during the check out. Thanks MT for taking my criticism constructively (as it was intended) and improving on your already stellar product.

How do I know? Because I’ve been building sites for a long time and for all that time I’ve had clients that have wanted to have budget-busting content management systems so that they could ‘manage everything’. In my early days I gave it to them, I gave them just want they wanted, and the backend admin always became the abandoned backwater of the site. (I know this because there are sign-in logs; I can see you haven’t signed in for 18 months).

Why does this happen? Because content management is complicated. Not complicated for people like me–computer people, web developers, people who make it their business to be good with websites–but for people like you, people who don’t want to be a ‘computer person’, people who have better things to do, like run their business or spend time with their family. I understand, software can be daunting and complicated and I’m not saying you’re stupid, far from it, you’re great at the stuff you’re great at but I know, I just know, that after the thrill of a new website wears off you won’t want to bother with making content updates.

What happens then? You call me. You say ‘Ryan, can you add this second phone number to the contact us page’ or you say ‘Ryan, so-and-so no longer works here, take him off the management team page’ and I say ‘no problem’ and I make the changes. I’ll do this work for you even though I built you a content management system to update the contact us page and the management team page. I’ll do it because I understand that you don’t want to go poking around for usernames and passwords and clicking edit buttons and updating WYSIWYG textareas, you just want it changed.

And I’m happy to do it, I get to charge for those 15 minutes and you’re happy because you don’t need to give it a second thought. But consider this, when I first created your site you said you wanted a content management system, and I put a price to that–a price that, incidentally, is higher than the cost of making a mostly static website–and we agreed to a budget and the work got done. But now you’re paying me to make changes, so you’re paying twice. This time let’s just acknowledge that you don’t really want to content manage everything, that your mailing address doesn’t change often enough to require that the page be content managed, and that if something needs to change, you can drop me a line or an email and I’ll get to it this afternoon?

Now, I hear you, there are some things that make sense to content manage. Things that are highly structured and repetitive, like news or events or PDF newsletters; things that you might want to change every week and calling me would get tiresome (and expensive in the long run). Ok, so let’s manage those, but all the same, consider if your site really needs these features. I had a client that only wanted to content managed their news, and I programmed a tool to do that, and last October I stopped by the site and saw a ‘Happy Halloween’ message and I thought: ‘Great, they are using the news’. Then I noticed that the dateline was from 2008. Some people think not having news on your sites is bad– you know what’s worse?–having news that’s two years old. If you’re going to content manage, even a little bit, you’ve got to do it.

I sense that you’re still hesitant. Let me propose a little experiment. Let me develop your site the way I think it should be, with an appropriate amount of content management, and we’ll let it run for, say, three to six months. After the trial period is over we can re-evaluate and decide if you really need a content management system. If you’re calling me morning, noon, and night then we know for sure that you would benefit from some more content management. However, if, as I suspect, you find that you don’t need to call me all that often, we can both agree that site is great the way it is and you can keep the money that you would have otherwise paid me to implement content management. It’s win-win (in the sense that you keep your money and I get to be proven right).

Now, this sounds like I’m trying to get out of doing work–that maybe I don’t understand the power of content management tools or that I can’t program one–that’s not the case. What I want is for you to have a website that’s sized right for you. My goal is always to create the simplest thing that will get the job done and implementing fully featured content management systems necessarily introduces a significant level of complexity to a website. And that’s fine if it’s truly necessary, but it so seldom is. Why introduce complexity and higher costs when you don’t need too? Better to have a straightforward site and my phone number near by (or another developer’s phone number, because simple sites are simple for anyone to update) then to pay for a Ferrari when you only need a family sedan.

So, please, let’s put aside this idea of the all dominating content management system and works towards something more reasonable. I know it’s not as sexy or exciting but I also know that no matter how optimistic you are right now you’re still going to be calling me in six months to remove Helen from the accounting page.

First, cron jobs should ideally be created using the Scheduled Tasks tool found in Plesk. Under the Websites & Domains tab click the “show advanced operations” link to disclose more options. Scheduled Tasks should be there as an option and if you click through and then click the system user you can add a new task, fill in the details and away you go.

Problem is, it didn’t work. I set up the cron job accurately but it wouldn’t execute. Not only that, the cron log wasn’t listing any errors. I had to dig a little deeper and to do that I ssh’d on to the server as the root user.

An important tool for monitoring cron jobs is the cron log. You can view the end of cron log by issuing the following command:

tail /var/log/cron

This will show a line for every cron job that has been recently executed. Plesk sets up a few jobs for the root user to run so you should see those in there as jobs the cron daemon (crond) has executed as (root). If you set up a cron job through Plesk’s scheduled task tool you should also see the jobs logged.

An interesting (and perhaps crucial) thing to note is that cron jobs aren’t all executed as (root) but by the user that added the job to the system. This is important because cron tasks are executed with the permissions of the the user who created the task. It is quite possible that the commands I was asking cron to run could not be executed by the system username user due to permissions problems. However, I spent an hour trying different chown and chmod permission combinations trying to get my shell script and the commands therein to work for the system username and I found no joy.

As an aside I want to describe how I structure cron jobs in general. First, I create a bash shell script and put it below the webroot. I usually name it _cron.sh and I create it through the ftp. A very straightforward example of the shell script follows:

#!/bin/bash
/usr/bin/curl http://www.domain.com/_cron.php

The first bit is the bash shell shebang that dictates what language the script is written for and the second line is a command line command that calls a php file on my server. Now, I use curl to actually call the page using HTTP. I know some people use command line php and that works great too but I like using curl because I usually have the _cron.php file doing some work in the CMS and it’s best structured as a web page rather than a command line script. Inside _cron.php, to test, I insert the current time into a test database so that I can have some evidence that the code executed. When the cron job is working fine I re-write _cron.php to do whatever I want.

I like this approach for two reasons. First, you can change the PHP file or the shell script without having to stop and start the cron daemon or create a new job. Second, it’s easy to test each step. You can test the _cron.php script by visiting it in a browser to see if it works. Next, you can call the shell script direct from the command line and see if that works. Finally, you can have the cron job fire and see if it all works. If the code doesn’t work somewhere along the line you can pinpoint where the problem is. Case in point, when I was trying to use scheduled tasks to do the database insert, the problem was with the since the command line and browser visits worked fine.

Back to the DV 4. Plesk keeps the crontab, or list of all cron jobs, in a file unique to every user. The files can be found in /var/spool/cron. There is a file for root that lists all the root jobs and a file for every other user that has jobs (including the system username user if you created a scheduled task through Plesk). Listing the contents of these files is not very illuminating but it does demonstrate that the cron job created by scheduled tasks is well formed and ready to be executed by the cron daemon. This is what was so frustrating about Scheduled Tasks, everything looks right, it just doesn’t work.

So, what to do? I was pretty fed up after a couple of hours of head scratching and I decided that since root’s cron jobs were running just fine I would move my job over to root. To do this I needed to edit the root crontab by issuing the following command (when ssh’d in as root):

crontab -e

This opens root’s crontab in vi. Insert a new line after the last cron job and enter the new job’s information:

*       *       *       *       *       /var/www/vhosts/domain.com/_cron.sh

A brief refresher on cron syntax. The asterisk means ‘all’ so this cron job will actually run every minute. This is good for testing since you’ll want to see results right away. Every asterisk is separated by a tab not just spaces. The command is an absolute path to the shell script I mentioned earlier. Do not hit return after adding this line (i.e. don’t add an empty line at the end of the crontab). Save and quit vi.

Now that the root crontab has been changed you’ll need to restart the cron daemon:

/etc/init.d/crond restat

One thing, chmod the cron shell script so that it can be executed by root:

chmod 744 /var/www/vhosts/domain.com/_cron.sh

After all this the cron job should start executing. In my example it means that every minute I see a new row being inserted into my test database table. This means that cron is properly calling my _cron.sh shell script and the shell script is properly curling my _cron.php file. Everything is right with the world.

Finally, edit root’s crontab again and change the frequency of the cron job (unless you really want it to fire every minute). My code, for example, fires once a day to clean some database stuff up. I have it fire at 4:01 AM:

1      4       *       *       *       /var/www/vhosts/domain.com/_cron.sh

While this isn’t the best way to get a cron job working and I am disappointed that I couldn’t figure out scheduled tasks I am pleased with the result and I hope this helps someone out.

The first wrinkle I ran into on Cirrus Tech was setting up a subdomain. It’s a little more complicated than MT and I wasn’t able to find any help on the web.

The first part of setting up a subdomain will be familiar to anyone who has used Plesk 9 to perform this task. Sign into the Plesk control panel and select ‘Domains’ from the left panel. Then click on the base domain name that needs the subdomain. Find the ‘Subdomains’ icon on the next page and click it. When the page finishes loading click the ‘Create Subdomain’ icon, fill in the details on the next page and click ‘Finish’. If you look on the FTP for the domain (assuming you kept the same FTP user for the subdomain as for the base domain) you will see the new subdomain under the /subdomains folder.

On Media Temple this would be the end of it and the subdomain would be wired up. On Cirrus Tech, we’re not done. Since the Cirrus Tech server is functioning as the primary namerserver for the domain’s DNS Zone what we need to do is create a new DNS A record for the subdomain. Now, back on the page with all the icons, the one with the ‘Subdomains’ icon, you may recall having seen an icon called ‘DNS Settings’ and on that page is an ‘Add Record’ option. THIS IS NOT THE ONE YOU WANT. Any A Records you create using that tool will not change a thing.

Where you want to do this work is in the Cirrus Tech control panel. This panel is, in my mind, analogous to Media Temple’s account centre, although it is also has a Plesk interface. Sign into this panel using your Cirrus Tech account credentials (not your Plesk ‘admin’ account). To add the A Records click on the ‘System’ tab at the top, then click ‘All My Domains’ on the left under ‘Domain Management’, then the base domain, then click the ‘DNS Zone’ tab and finally click the ‘New Record’ icon.

This will offer up a form that can be filled in to add an A Record for the subdomain that was created earlier. The name field contains the name of the subdomain, the ‘Type’ is ‘A’ for A Record, and the ‘Value’ is the IP address for your site which is usually the same as the IP address of the first Plesk panel you were using. Fill in the details, click ‘Save’, and the A Record will be added. After that the subdomain will be ready to go.

Hope this helps someone.

The first that you need to do is have SSH access to the server. As I’ve said before, MT has a wiki for that, so get yourself set up as the root user on your server.

Change directories to your domain directory and create a temp folder for Sphinx.

cd /var/www/vhosts/{domain.com}/
mkdir sphinx_temp

Next you need to visit the Sphinx downloads page and decide which version you want to download. At the time of this post the latest stable version was 2.0.1-beta. Click on the version you want to download to get to the package listing page. Copy the download url for the “source tarball” package.

Back on the server, move into temp directory you created and use wget to download the Sphinx package.

cd sphinx_temp
wget http://sphinxsearch.com/files/sphinx-2.0.1-beta.tar.gz

This will download the tarball to your temp directory. Now untar it and move into the folder that is created.

tar -xzvf sphinx-2.0.1-beta.tar.gz
cd sphinx-2.0.1-beta

Now run the configure script with the “prefix” flag to indicate where Sphinx should be installed.

./configure --prefix=/usr/local/sphinx

The MT DV 4 server already has the /usr/local directory but you need to be the root user to be able to create the Sphinx directory. This is where the Sphinx bin and config folders are so remember it.

Around the Internet you’ll find that some blog posts and tutorials say that the configure command needs a flag that indicates where the mysql drivers are installed. If the mysql-devel tools are installed on the MT server already — and they should be as they part of the larger developer tools that you can install through the MT Account Center when you activate root access — you don’t need to do this since Sphinx can find the package on its own (Hooray for default installations).

Now you need to issue the make and make install commands.

make
make install

It’s normal for the make command to take a bit of time to complete. Also, the make install command may look like it doesn’t accomplish anything. There aren’t any errors per se but it doesn’t do much. Regardless, Sphinx still works so just jump through the hoops and you’ll be done. Finally, delete the temp Sphinx folder you created so your server isn’t cluttered.

Next time I’ll write about indexing and searching with Sphinx.

On DV 3.X the vhost.conf file that adjusts open_basedir’s permissions is read when the server is restarted. This is not the case on DV 4. If you create the vhost.conf file and reboot the server Apache will not integrate the changes. This can lead to a lot of confusion since this is exactly how it used to work on DV 3.X.

If you cd into the /var/www/vhosts/example.com/conf/ on a DV 4 server and issue an ls you’ll see a number of http.include files that have a unix time stamp prepended to them. The most recent file is the one that currently configures Apache. What we need to do is instruct Plesk to create a new http.include file that integrate vhost.conf and override the default settings.

First, create the vhost.conf file as before. Second, instead of rebooting the httpd daemon as on DV 3.X issue the following command:

/usr/local/psa/admin/bin/httpdmng --reconfigure-all

This command will create a new http.include file in the conf folder that honours the directives found in vhost.conf.

In the old days, on DV 3, a subdomain was created through the Plesk panel by clicking the Subdomains icon and filling in the subdomain name, password and services. Plesk then created a folder for the subdomain under the /subdomains folder in the FTP root.

Under DV 4 the process is similar but different enough to cause some confusion. First, log into Plesk and click the “Websites & Domains” tab at the top. At the bottom of that page is a button to “Add New Subdomain” and clicking it will take you to a page that asks for the subdomain name and the document root.

This is where it gets a bit weird. The subdomain name is straightforward enough but the document root is a new element. Let’s say that we are creating a subdomain named “blog”. You might assume that if we set the document root to be “/blog” that the folder for the subdomain would end up being /subdomains/blog. This is not the case. The folder for the subdomain is actually /blog, right in the root of the FTP along with /subdomains, /httpdocs, /statistics and all the rest.

But wait, it gets a little weirder. Say you don’ t want the folder there, that you like it in the /subdomains folder the way it used to be, so you specify the document root as /subdomains/blog when you are creating the new subdomain. Nope, that raises an error because /subdomains is a system folder and you can’t mess with it. Ok, fine, you accept that the subdomain folder has to be off the FTP root, not a big deal really, but then you happen to click through to the /subdomains folder to have a look. Lo, what do we see, folders created for the subdomain? Yeah, that’s right, Plesk still creates a directory for your subdomain in /subdomains and, if you click through, you’ll see that it’s full of support directories such as cgi-bin, conf, and error_docs. Nowhere to be seen is httpdocs, though, because that’s what the new FTP root folder is. Also notice that the directory in /subdomains is named after your subdomain name, not the document root you provided so if you created a subdomain with the name http://president.blog.domain.com and the document root /president-blog the folder in /subdomains will be named /president.blog while the folder in the FTP root will be named /president-blog.

So let’s recap. When you create a subdomain through Plesk it asks for the subdomain name and the document root. Plesk will then proceed to create a directory within /subdomains named after the subdomain name you provided and fill that directory with the typical Plesk support directories, but not httpdocs. To find the directory your files are being hosted out of you need to look off the FTP root for the directory named the same as the document root your provided during set up. Also, this directory does not contain an httpdocs directory, the site’s files are served straight from the document root name you provided.

In the grand scheme of the things, this isn’t a big deal. In fact, now that I’m used to the way things are set up I actually like it a bit better because it means I don’t have to drill into subdomains -> subdomain_name -> httpdocs every time I want to make an edit. However, for those of us used to the way files were set up on DV 3 the new layout is a little discombobulating. I hope this post helps someone clear up their confusion.

Common Bits and Pieces

Form Related

Common Error Messages

Miscellaneous Odds and Sods