package { "openssh-server":
      ensure  => latest,
      notify  => Service["sshd"],
}
file { "sshd_config":
       name     => "/etc/ssh/sshd_config",
       checksum => md5,
       ensure   => present,
       owner    => 'root',
       group    => 'root',
       mode     => '0600',
       require  => Package["openssh-server"],
       notify   => Service["sshd"],
}
service { "sshd":
       name       => "sshd",
       ensure     => running,
       enable     => true,
       hasrestart => true,
       hasstatus  => true,
       require => Package["openssh-server"],
}

This 22 line recipe does all of the following:

1. Installs the openssh-server RPM via ‘yum’.
2. Automatically upgrades the openssh-server RPM, if a newer version is available.
3. Makes sure the sshd_config configuration file exists and has the proper permissions.
4. Ensure the sshd server starts at boot time.
5. Ensure the sshd server is currently running.
6. If either the RPM is upgraded OR the sshd_config file changes restart the sshd service.
7. If during any time puppet runs again and the server doesn’t match the recipe it will change it back to this state.
8. Perform this task on every server you specify.

While the above recipe hasn’t been tested on other Unix platforms, only minor changes would be required.  Previously to do this you needed to create custom shell scripts, use Cfengine, purchase an expensive software automation tool, or manually perform this on each server installation.  Most options are hacks and not as graceful as Puppet. Package managers, while moved Unix administration into the 21st century (instead of the medieval times of compiling software), still have some warts.  Specifically package managers lack:

1. a good updating procedure.  Installations are well covered.
2. passing your own configuration files specific to your needs/wants.
3. performing the tasks in a specific order, or making sure specific actions occur before an application is installed
4. a service is running and will run at boot time

Things like ‘yum’ on CentOS/RHEL addressed #1 and #3 somewhat, but didn’t address configuration files, and the state of the service.  Before Puppet, it required creating custom RPMs.  With custom RPMs, the issue then became when updates occurred from the distro provider.

Puppet makes system administration a programming task, rather then manual labor process. It’s still very common to see administrators use a SSH prompt to manage each server. Manually performing administration is a time consuming and error prone process.  Puppet allows us a transfer of our best practices, apply our administration experience to the server’s configuration, and allows us to make network-wide installations with ease.

I agree with the notion; “Operations: The New Secret Sauce” (article #1 , article #2).  Puppet makes deployment of new VPS instances quick and exact.   System administrators are skilled individuals, great with keeping operations running smoothly, but usually not good with automation.  Puppet allows to transfer an administrator’s knowledge into a repeatable process.  Automating system administration is the next advancement with Web 2.0, Cloud Computing, SaaS, or whatever the latest trend may be called.  When using our HostCube service, Puppet puts the power of a large operations center like Google in the hands of much smaller companies, Cloud computing, while may address the quick provisioning of hardware, it doesn’t address operations. The ability to automate the install, configure, patch, monitor and backup are important aspects and HostCube does for you automatically and seamlessly.  The bigger and much more complex problem is system administration, not hardware provisioning.

Puppet allows us to Malkovich a setup, over and over and over again.

Existing 10for10 or custom plans may want to migrate to the new HostASite.com plans. Please contact billing to discuss any changes. If unsure, your control panel will display your hosting plan. If your plan is one of the above entries, and not labeled “custom”, it has automatically been upgraded and no action is necessary.

If you’ve outgrown our HostASite.com plans, we suggest visiting our managed VPS service HostCube. Managed VPSes give you dedicated CPU, dedicated memory, dedicated disk space, additional security, customization, and the support you’ve grown to know and love.  It’s like getting a dedicated server but at the fraction of the cost. HostCube VPSes are perfect for the reseller, web developer, or designer who needs to scale quickly and easily and not perform time consuming system administration.

The primary reasons for using a VPS:

• Dedicated resources (Quality of Service).
• More control of installed software.
• More secure.
• Dedicated IP address.

With shared hosting the hosting provider has to make sure each customer’s hosting configuration performs well. The administrator might be able to perform proactive measures, but in many cases this isn’t possible. This is because each shared hosting account uses the same memory, CPU and disk space. This is similar to a noisy neighbor in a massive apartment building. All it takes is one bad tenant to affect the others. Each customer must share the same resources on a shared hosting server.

Dedicated Resources (Quality of Service)

With a VPS you are allocated a fixed amount of resources (just like a dedicated server) and these resources are dedicated to you. Each customer is separated at the operating system level and another customer cannot affect your VPS. This increases quality of service since you have a specific amount of memory, CPU and disk given to your account. This is also the main reason for the differences in price between VPS and shared hosting.

A common issue on many oversold shared hosting providers is that you are suspended once you use too much CPU, memory or disk space. On a VPS you will never get suspended for this reason. Also, shared hosting’s dirty little secret is that many dynamically generated web pages (i.e. blog, forum, CMS, E-commerce) are primarily CPU bound. On a massively oversold shared server there is only so much CPU to go around.  These providers put 500-600 accounts on each server and for this reason the performance of ALL clients on that server is affected.

Other Advantages of Choosing a VPS Solution Include:

More Control of Installed Software

With a VPS we can customize the software to the customer’s exact specifications. Since software such as apache, PHP, MySQL, etc are dedicated to just your account. Conversely, shared hosting is configured to please the majority and exceptions are not possible. In addition, if you need a service (otherwise known as a daemon) running or custom programming libraries, this is all possible with a VPS.

More Secure

Since each VPS is separated at the operating system level, each customer is running in its own memory, CPU and disk space. This prevents your account from getting compromised when another customer forgets to update to their blog software to fix security risks that have been discovered – if hackers get into their shared hosting account they can quickly move horizontally into your account if you’re on the same shared server.

Dedicated IP address

This is important for any service that uses the source IP address for reputation purposes. This is extremely important with outbound E-mail (SMTP) and significantly decreases the chance of blockage because another customer sent out spam. To put this in perspective, we’ve seen cases where one misguided salesperson sending out less than 200 emails in an email blast has caused IP-based blocking of an entire IP (including all the responsible senders on that IP).

The HostCube Advantage

There’s one advantage that can sometimes be at credited to shared hosting: the provider manages all the system administration. Fortunately, this service is also provided when using a service like HostCube Managed VPS. The components of system administration include:

• Backups
• Service monitoring
• Security monitoring
• Software updates
• Software configuration

There’s no need to worry if your VPS is secure, and is your site running as our managed VPSes give you the best of both worlds: the ability to work as if in a shared hosting environment with the performance of a dedicated server.

Using 777 permissions on a folder means ANYONE on that server can write to it. Hackers LOVE this type of setup. In addition, with mod_php you must have at least 644 perms on PHP files, which ALSO means your files can be read by anyone. This means your MySQL password, key to your merchant account, etc., can be read by any customer on that shared server! If you ask me, not a secure solution.

We use suPHP instead of the default apache/mod_php for shared hosting.

SuPHP
Pros:

• PHP runs as your user/group
• PHP files can have perms of 640 (hiding things like passwords from other accounts)
• Files/folders written by PHP are written as user/group (no apache or other global user)
• Custom php.ini file per site (can add/remove security options)
• Can run php4 and php5 at the same time (on even the same site!)

Cons:

• Slower
• many PHP .htaccess options do not work (since you can have your own php.ini file this make this point moot)

apache/mod_php
Pros:

• Faster (about 25-30%)

Cons

• PHP safe mode isn’t safe
• files written by PHP are saved as the apache process (usually apache/apache user/group)

For our small business web hosting customers it’s a no brainer to use suPHP instead of mod_php, even if we take a performance hit. PHP is the #1 method hackers gain access to customer accounts. So once an account is hacked on a shared server, they can do much more damage with a mod_php setup. SuPHP accounts are much more sandboxed. We’ve had many hacked accounts via suPHP, and none of them have affected our other customers. In the future are going to replace suPHP and use LiteSpeed’s web server instead. It offers the same performance as mod_php and yet the same security as suPHP.

Our Managed VPS web hosting we give the customer the option to select which PHP setup they want.

• EC2 pay as your go service, while cheap for low CPU/bandwidth usage, can get very costly compared to our fixed plans. With HostCube there are no surprises at the end of the month. Most of today’s Internet applications are CPU bound and EC2 can get very costly in this regard.
• No hardware based load balancer, important for scaling or automatic fail over.
• No persistent storage unless you use their S3 service. Shutdown or the node dies; your data and configuration settings are gone. Using S3 service your disk I/O traffic then becomes network bound and of course is an additional fee.
• When compared to our managed VPSes, you must perform all of the system administration yourself. This IMHO is the biggest added value when comparing services. Our service already includes backups, monitoring, administration, patch management, security, and a control panel that makes many administration tasks a simple click. With EC2 you must be much more involved with the system administration.
• Technical support with EC2 is an additional option. What’s not clear is how much support you really get. Can they assist and give recommendations on how to scale your site?
• Odd instance sizes (1.7 GB of memory, 350GB of storage?) what is that? Computing is based upon the multiples of 2.
• 32-bit by default. We, by default, use 64-bit which is 10-15% faster than the 32 bit version.  It appears you have to use the their Extra Large instance to get 64-bit.  This really becomes noticeable when you use more than 2GB of ram.  Not sure with Amazon but all of our nodes are using 64 bit based Xen.  The hypervisor is really where the performance matters.

In brief, EC2 is really geared towards batch based processing and processing services in low volume. If you need public service access (i.e. web service) and hassle-free administration HostCube is a perfect fit and a much better value.

While the HostCube service has some shortcomings, we are adding services like shared storage, quick (under 15 min.) provisioning and an API in the near future.