Archive

Archive for the ‘System Administration’ Category

External DNS at 1and1

June 10th, 2009

If you have your DNS hosted in one place (say DNS Made Easy) but host your content on 1and1.com. 1and1 allows you to do this without transferring the domain to them. The problem is they appear to not set the DirectoryIndex directive for hosts using external DNS. This can be overcome with either creating or adding to the .htaccess file in your site’s root directory:

DirectoryIndex index.php

That’ll work for WordPress, or most other PHP-based sites. You can always change it to index.html if that’s what your site’s index page is.

System Administration , ,

How to Start sshd On Plesk

June 9th, 2009

I had a client machine reboot today and ssh wasn’t configured to come up on boot. This was a CentOS Plesk machine at my least favorite hosting provider, Media Temple. Secure shell isn’t mentioned in the services section in Plesk, and Media Temple doesn’t have a remote console feature. So in order to avoid submitting a ticket and waiting for Media Temple’s slow support, I managed to restart sshd using Plesk’s web interface to cron (Scheduled Tasks) to start it. Here’s what I did:

  • Got the current server time (it might not be in your timezone) by going to Server > Time
  • Went to Server > Scheduled Tasks and created a new scheduled task 2 minutes ahead of the current server time. The task should run /etc/init.d/sshd start.
  • Wait.

Hopefully within 2 minutes sshd is started. Don’t forget to remove the scheduled task, and ensure that sshd is configured to start on boot (chkconfig –levels 345 sshd start or whatever your distro uses.) Honestly I think Media Temple should have a backend console similar to how other VPS providers such as Slice and Linode do it. You’re paying enough. :)

System Administration , ,

Apache restarts with vlad

April 30th, 2009

Often when deploying a new web application you need to restart the apache process. If you’re deploying the application with vlad the deployer as a non-root user (which you should be doing) and you need to restart apache, this can be a little tricky. Luckily there’s a Linux command called sudo which allows you to run commands from a non-root user’s account as though you were root. We’ll limit the commands to just controlling the apache process. It’s a bad idea to give open access with sudo since the user can simply run “sudo su -” and become root.

In order to edit the configuration file that sudo uses (/etc/sudoers btw) we use the visudo command, which edits the file in a safe way by checking for simultaneous users editing the file, parse errors, etc. The idea being to minimize the number of mistakes that can be made. You’ll need to be root (or have sudo permission!) to edit the file:

  # visudo

This brings up an editor screen, whatever you have configured as your default editor. The example below is for Ubuntu, so if you’re using a different distro or web server you’ll need to change the location of the init scripts accordingly (i.e. Ubuntu uses /etc/init.d/apache2 but your distro may use /etc/init.d/httpd or /etc/init.d/lighttpd if you’re running Lighttpd.) I’ll also assume you’re calling the deployment user deploy.

Here are the lines you want to add:

Cmnd_Alias     APACHE = /etc/init.d/apache2 start, /etc/init.d/apache2 stop, /etc/init.d/apache2 restart, /etc/init.d/apache2 reload
# Allow the deploy user to control apache
deploy ALL=NOPASSWD: APACHE

Now save the file, and log in as your deploy user. You should be able to restart apache with the above commands by running:

deploy@steve:~$ sudo /etc/init.d/apache2 restart

Now in your vlad tasks, use the sudo version above to kick the webserver over when you do a deploy:

         # desc "Starts Apache"
         remote_task :start => :settings do
             run 'sudo /etc/init.d/apache2 start'
         end

         # desc "Restarts Apache"
         remote_task :restart => :settings do
             run 'sudo /etc/init.d/apache2 restart'
         end

         # desc "Stop Apache"
         remote_task :stop => :settings do
             run 'sudo /etc/init.d/apache2 stop'
         end

System Administration ,

cPanel Upload Only FTP

April 2nd, 2009

In some cases you want to set up an “upload only” FTP account, which allows a user to upload files, but not list directories, download or delete files. This is typically used when you want to give out the credentials for an account to multiple people so they can upload content (mp3s, videos, resumes, etc.) but not affect what others are doing.

cPanel gives you two choices of FTP server - PureFTP or ProFTP. PureFTP is simpler and smaller if you just want a quick and dirty FTP site. For more advanced configuration, ProFTP is recommended. ProFTP has a feature that is a lot like Apache’s .htaccess file, allowing you do make per-directory configurations without modifying the main config file. Any directives that can appear in a ProFTP <Directory> stanza can appear in an .ftpaccess file and will be applied to the directory in which the file resides.

First make sure you’re running ProFTP and not PureFTP - you can change this setting with no loss of information from within WHM. If you don’t have WHM access, you’ll need to ask your provider to switch FTP servers. Here’s the config for an upload-only FTP account called ‘uploadonly’ - the account will need to have been created from cPanel first. Name this file .ftpaccess and put it in the directory where you want the uploads to appear. I usually create a separate directory and apply quotas.

    <Limit ALL>
        DenyUser uploadonly
    </Limit>

     <Limit CDUP CWD XCWD XCUP>
        AllowUser uploadonly
    </Limit>

    <Limit STOR STOU>
        AllowUser uploadonly
    </Limit>

This type of configuration where we deny everything, then allow only what we want is more secure than allowing everything and denying specific operations. More configuration options are shown on ProFTP’s configuration page - anything that can belong in a <Directory> stanza can go in the .ftpaccess file and avoids having to edit cPanel’s ProFTP configuration file.

System Administration , ,

Service Review: DNS Made Easy

March 12th, 2009

When clients ask me to recommend a DNS provider, I used to suggest UltraDNS. UltraDNS uses Anycast routing which gives DDoS protection as well as excellent performance, since clients get service from servers that are closer to them. UltraDNS has massive redundancy, which also makes it a great choice from a security perspective. I started using DNS Made Easy about 2 months ago and I was blown away. They use the same Anycast technology UltraDNS does, they have redundant servers (they added 100 servers to their network last year) in multiple countries, their interface is clear, simple and easy to use, and most importantly they are a fraction of the cost of UltraDNS. Their most expensive package has more queries than you’ll ever need and is still less than $150/month. Smaller sites would be able to use their less expensive package which is a little over a dollar a month ($14.95/year.)

The DNS Made Easy interface is really simple to use, unlike a lot of the DNS managers from web-hosting companies such as GoDaddy or 1&1. Adding domain-level redirects is extremely simple and straightforward, as are the usual suspects like adding A records, CNAMEs and setting TTLs. One feature I really like from DNS Made Easy is the ability to do a “soft” redirect. If you change your domain, you need to redirect your old URLs to the new one. This is especially important if you have a lot of indexed pages. DNS Made Easy has a “soft” redirect feature, which keeps the path information for the new URL. This means your URLs that are currently indexed (http://olddomain.com/some/indexed/url.html) gets redirected to the “right” place on the new domain (http://newdomain.com/some/indexed/url.html). The same thing can be done using an Apache rewrite rule if you don’t want to use DNS Made Easy. For example, a 301 “soft” redirect to newdomain.com:


RewriteEngine on
RewriteBase /
RewriteRule ^(.*)$ http://newdomain.com/$1 [R=301,L]

One thing that turns a lot of people off about UltraDNS is the cost. DNS Made Easy is based on the same AnyCast technology but is much, much cheaper. For a little over a dollar a month you get 3 domains with 1 million DNS queries per month. With UltraDNS being $100 per 1,000 queries, the prices don’t even compare. Also, UltraDNS charges by resource record (i.e. the more A, MX, CNAME records you have, the more you pay) but DNS Made Easy does not.

As a final note, even if you’re not convinced to use DNS Made Easy for your primary DNS needs, it is an inexpensive way to have secondary DNS in case your primaries go offline. DNS Made Easy can act as a slave for your own master running BIND. This is a great combination for those of us who like to do it ourselves but don’t have the resources (or money!) to build our own redundant, Anycast network.

Note that this review was not paid for, or endorsed by DNS Made Easy. Nor am I an affiliate.

System Administration ,

Dedicated Proxies for SEO and Developers

March 10th, 2009

Most people, SEOs especially will have heard of and understand what proxies are. For those of you who don’t know, proxies allow you to “tunnel” your browser’s traffic through another computer, making it seem like you are surfing the web from that location. There are specific services out there that make your traffic more anonymous by doing other things like blocking cookies, or even certain sites. Those web filters that keep our kids “safe” are a type of proxy (although most are easily bypassed.) Most proxies are owned by companies to which you pay a fee for their use, or you can search for “open proxy list” to find some. The downside to using these is mainly lack of control - you have no control over if the proxy is forwarding HTTP headers (making it known that you’re using a proxy), no control over DNS or who else is using the proxy. I’ll explain why these are important shortly.

If you’re optimizing for US-based or UK-based traffic it doesn’t make sense to check your SERP ranking from Canada. What if your site is in a foreign language such as Italian? It makes more sense to search from an IP that is geographically located in the area you’re trying to analyze. That’s where proxies come in. You simply have a web proxy set up in a data centre in the right country and you’ll instantly have a more accurate picture of where you rank in the SERPs. We can set proxies up in a variety of locations such as Canada, US, UK, or other European countries such as France and Germany.. These are dedicated servers with dedicated IP addresses, configured to not add HTTP headers that tell others you’re proxying. These servers are dedicated to you, and cannot be used by anyone else. If you’re interested in having us set up one or more proxies for you, please contact us.

If you run any kind of SEO tool, you’ll know proxies are a must. Those of us without Google API keys must rely on “scraper” type tools that do repeated searches. These tools are not scalable from one IP, meaning you hit a threshold and your tool stops working (I hate it when that happens.) If you proxy your requests through several different dedicated proxies, you can avoid this. And for those of you who use open proxy lists - they are unreliable, slow, insecure and remember that you have the list as well as thousands of others, including the search engine companies. Dedicated proxies are reliable, fast and they belong to you. You control who has access from where.

Developers can use dedicated proxies to test applications quite easily. This is especially important if your software does anything with IP geolocation data, such as taking users from the UK to a different domain. The only surefire way to test this is from a UK-based IP. Perhaps you’re in the process of upgrading your site and want to test it one the “live” domain name before making the DNS switch. You control the DNS resolution on your proxy, so you can make your site resolve to a different IP through the proxy. This allows you to flip back and forth between the old and new sites.

If you’re interested in having a dedicated proxy set up, please contact us for a quote. Hosted proxies run at $50/month for North America and most European countries and includes setup, monitoring and updates such as adding more users. If you have your own server already and just want us to configure the software and firewall it is a one-time cost of $100.

System Administration , ,

RedHat init Script For trac

January 15th, 2009

I found a few init scripts for trac, but they were all Debian-based, using ’start-stop-daemon’ which does not exist in RedHat-based distros. Here’s an init script that will work with RedHat.

#!/bin/bash
#
# tracd Start/Stop tracd.
#
# chkconfig: - 62 38
# description: tracd
#
# processname: tracd
#
# Author: Elliot (info@m7tech.net)

# Source function library
. /etc/init.d/functions

# Get network config
. /etc/sysconfig/network

RETVAL=0

TRACD_PORT=8000
TRACD_USER=tracd
DAEMON=/usr/bin/tracd
PIDFILE=/var/lock/subsys/tracd
TRACD_DIR=/subversion/trac

start() {
    echo -n $"Starting tracd: "
    daemon --user $TRACD_USER $DAEMON --port=$TRACD_PORT --daemonize \
                 --env-parent-dir=$TRACD_DIR
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch $PIDFILE
    return $RETVAL
}

stop() {
    echo -n $"Stopping tracd: "
    killproc tracd
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f $PIDFILE
    return $RETVAL
}    

restart() {
    stop
    start
}    

reload() {
    stop
    start
}

case "$1" in
  start)
      start
    ;;
  stop)
      stop
    ;;
  status)
    status tracd
    ;;
  restart)
      restart
    ;;
  condrestart)
      [ -f $PIDFILE ] && restart || :
    ;;
  reload)
    reload
    ;;
  *)
    echo $"Usage: $0 {start|stop|status|restart|condrestart|reload}"
    exit 1
esac

exit $?

System Administration ,