TechTalk

Topics in the world of web development and other technologies we find interesting.

Blue Valley Technologies - TechTalk

We want to give back! We have learned much of what we use everyday by others that have taken the time to post that information to the web. Here is where we will post the things that we hope will in turn be useful to others as we explore the technologies in web development and any other topics we find interesting.
 
You are free to use any of the code snips or techniques that we have posted here for any purpose, personal or commercial. However if we credit another individual or group please visit their website for information about their usage terms.

How to Backup up a Webserver

It is very important that any production use webserver have a robust backup plan. This generally is accomplished with the combination of a few strategies in order to protect your server from various types of problems.

File Backups

A good backup plan should first provide you with the ability to save backups of all the important files on the server to an offsite location. This allows you to recover any files accidently deleted / modified by the users, or due to file corruption, malicious malware, etc. We will share some scripts we have used in another post to roll your own scheduled file backups to S3 storage. Files should be saved at minimum at least daily, and for many sites more frequent copies may be desired.

Database Backups

When it comes to modern website applications, most of them rely on databases as well. So you will need to ensure that those databases are also backed up. Often the database and the files should be backed up as closely together as possible, to ensure their are not any concurrency issues. We will share some scripts we have used in another post to roll your own scheduled database backups for both MySQL as well as MS-SQL. If you are having trouble deciding how often is often enough, consider how much data loss would be acceptable to your business.  If your website accepts e-commerce orders, and you last all orders from the last 24 hours, would you have the info you need in other places, such as order confirmations in your email?

Disaster Recovery Backups

The idea behind a disaster recovery backup is that there may come a time when you need to restore everything, including the server and its operating system. This can be necessary if the server is no longer functioning properly, or it has been compromised by hackers and can no longer be trusted. To do this manually it can take hours, or sometimes even days of installing software, configuring services, and finally restoring the data itself. With a disaster recovery backup, you can restore to a known working point often in minutes, and then restore the files and data to the most recent point.

A disaster recovery backup does not need to be updated nearly as often, so long as the important file and database data is being backed up regularly. We typically update our disaster recovery backups every couple of months, or whenever we have made significant configuration changes to the server. If you use Amazon Web Services (AWS), Rackspace cloud hosting, or other cloud server offerings, the disaster recovery backup is easily accomplished with imaging or snapshotting the server instance and its related attached storage. If you are still using on-premise hardware for your webservers, you will need to use 3rd-party software for this backup.

A Good Backup Plan Needs Testing

If your business could suffer major losses when your website goes down, a backup plan is not a good plan until it has been tested.  Far too many system admins have learned the hard way, and too late that just because a backup said it completed succesfully, that there were crucial files missing, or things that just didn't work as planned. If your site is mission critical, than it is worth the time to occasionally stage a full server recovery on test hardware. Not only does this ensure that your backups are going to work when you need them, it will help you to know what to do to restore them under pressure when it really counts.

 

Posted by Mark at 12:10
Categories :

IIS 500 Errors when loading a static image in WordPress

I ran into this problem today and it was a frustrating one to track down. The WordPress site was a very basic blog running on IIS and using the freindly perma-links settings.

When loading a static image that had been uploaded in WordPress the browser would return a 500 error, and the IIS log would show: "GET /wp-content/uploads/2013/10/Sale.jpg - 80 - 192.168.0.133 Mozilla/5.0+(Windows+NT+6.2;+WOW64;+rv:24.0)+Gecko/20100101+Firefox/24.0 500 50 5 46"

I finally found the solution on another blog, posted by iis_isz.  I have copied the solution here to make sure I can find it again in the future, and for anyone else that has the same issue!

 

Explanation of the Error

The image issue was a permission issue, but simply setting it manually on the original image file or parent folder is inadequate.  The behavior of WordPress is that it writes the original file using IUSR to a temporary system directory that is defined in the PHP.ini file.  This temp folder does not have IIS_IUSRS permissions on it, so when windows moves this file from the temp folder to the application's upload folder, its final home, IIS_IUSRS only has read permissions, so the permissions are not inherited from the file's parent folder.

To fix this, there are two solutions

1. Change the permissions on the temp folder giving IIS_IUSRS write/modify.

2. Change the path of the temp folder in the PHP.ini file to a folder that does have IIS_IUSRS write/modify permission.

Here is a good source detailing the problem:

http://www.howyoudo.info/index.php/how-to-fix-windows-server-upload-file-inherit-permissions-error/

I chose to move the temp folder in my PHP.ini to C:\inetpub\temp\uploads and also give it permissions.

After uploading an image in wp-admin, I was able to access the image (original, not resized) from a browser wihout the 500.50 error.

 

 

Posted by Mark at 12:26
Categories :

Creating a Rackspace Ubuntu Cloud Server

Rackspace Cloud servers are ultra-reliable and robust cloud based servers that can be configured with a variety base OS images. This walkthrough will take you step by step through creating and setting a base install of the popular Ubuntu 10.04 LTS (Lucid Lynx). Later walkthroughs will pick up where this walkthrough leaves off with setting up common webserver platforms and frameworks.

We begin by logging into our Rackspace Cloud Server control panel.

  1. Add new server instance.
  2. Select Linux tab, then Ubuntu 10.04 LTS (Lucid).
  3. Type a unique name to identify the new server.
  4. Select the desired hardware. I started with the least expensive; it is easy to scale up later if needed.
  5. The Rackspace panel will give you a pre-generated password. Save this for later reference.
  6. While the server is building you will want to install an SSH Client. If you are on Windows we recommend Bitvise Tunnelier (free for individual use).
  7. Once the server build is complete, you will get an email with the public IP address and the root/admin password for your new Linux server.
  8. Open your SSH Client and connect to the new server with the public IP address as the Host, Default Port 22, root for the username, and the auto-generated password from earlier for the password.  On successful connection you should get a console command window.
  9. The first thing we should do is changed the root password. Since the auto-generated one was sent unencrypted via email it can no longer be considered safe. At the console prompt, type the command: passwd and hit enter. You will be prompted for the new password twice. Be sure to use an unique password that is fairly long, contains a mix of letters, numbers and at least one punctuation character. Save the new password in a secure location.

At this point you will have a working base install of Ubuntu 10.04 LTS (Lucid) running on a Rackspace Cloud Server. The next walk through will help take you step by step for Installing the LAMP Frawework stack.

Posted by Mark at 13:27
Categories :

Setting up LAMP server on Ubuntu 10.04 (Lucid Lynx)

LAMP is an acronym for the Linux Apache MySQL PHP stack, which is a very popular web development framework. This walkthrough will guide you step by step the process of installing a base LAMP stack on a clean Ubuntu 10.04 (Lucid Lynx) server. If you do not already have an Ubuntu server, our previous walkthrough Creating a Rackspace Ubuntu Cloud Server will take you up to the point that this walkthrough picks up.

SSH into your Ubuntu server (see our Ubuntu setup walkthrough if you need help with this step)

  1. Update the installer source repositories by typing the following command:
    sudo apt-get update (hit enter)
  2. Install Apache:
    sudo apt-get install apache2 (hit enter)
    Type Y to confirm.
  3. Once the Apache install is finished, you can confirm it works by opening a new browser window and browsing to either the local or public IP (http://ip-address) of your Ubuntu server. You should see a page that says "It Works!" if all went well.
  4. Install MySQL Server:
    sudo apt-get install mysql-server-5.1 (hit enter)
    Type Y to confirm.
    Enter a new password for the root MySQL user. Be sure to use a unique password that is fairly long, contains a mix of letters, numbers and at least one punctuation character. Save the password in a secure location.
  5. Install PHP 5:
    sudo apt-get install php5 (hit enter)
    Type Y to confirm.
  6. Install the GD library for PHP:
    sudo apt-get install php5-gd (hit enter)
    Restart Apache:
    /etc/init.d/apache2 restart (hit enter)

  7. Finally we now install the MySQL module for PHP:
    sudo apt-get install php5-mysql (hit enter)

Now we have a clean base install of a LAMP server running on Ubuntu 10.04 (Lucid Lynx). If you are using a Hyper V server or the Rackspace Cloud, now would be a great time to make a snapshot backup of your server. We will pick up from here on the next walkthrough with installing and configuring Drupal.

Posted by Mark at 13:27
Categories :

Introduction to ASP.NET Master Pages

ASP.NET has a built in website template system called Master Pages. The system offers a very flexible and easy to use solution for managing the portion of a website that will be re-used on more than one page of the site.

Most websites will use the same header, navigation and footer on almost every page of the site. Master Pages provide a simple to use, and simple to manage answer for this common problem. Master pages are not the only option for this problem. Some developers have taken the time to build their own templating system (usually when using another development language that does not already have one built-in like ASP.NET), and some web design software suites include a template system. For example, Dreamweaver includes a system called "Dreamweaver templates". ASP.NET Master pages work similar to the Editable Regions in Dreamweaver templates, but they offer a number of advantages.

  1. The master pages are integrated into the content pages at the time of the user request. This means that unlike client side based templates, you do not need to re-apply it to every content page each time you change the master page.
  2. The ASP.NET Master Pages are much more flexible than most other template systems. Among many other features, they allow for an unlimited number of nested template levels and allow for default content at each content region. While nesting is beyond the scope of this article, it is actually quite simple to implement. I will discuss how to specify default content below.

The template files in ASP.NET end with .master and are very similar to a standard .aspx page in that they can contain the same kind of page markup. The .master file will contain the code that you want to reuse on multiple pages.

In the example below you will see the Site.master default markup for a new Visual Studio Web Site. By default there are two Content Place Holders defined with the <asp:ContentPlaceHolder /> tags. The first one is titled HeadContent and contains a single line of default content. The second Content Place Holder is titled MainContent and uses the shorter close tag notation since we did not specify any default content for this region. Because the templates are actually merged by the web server at the time of the request, we need to include the runat="server" parameter as well.

Site.master ASP.Net Masterpage

In the sample Content Page below we tell the server that we want to use our Master Page by adding the MasterPageFile="~/Site.Master" parameter in the Page tag at the top. The Master Pages content will now automatically be used on this page of the website and all we need to do is optionally provide some custom content for our Content Place Holders. We do this by using a <asp:Content /> tag. The page below has supplied content for both of our Content Place Holders. Notice how the tags are matched to their proper corresponding Master Page tag by the ContenPlaceHolderId parameter.

Default.aspx ASP.Net Page inheriting from Site.master

If we request the page from the web server, below is the resulting HTML that is sent to the browser. The custom content was automatically merged with the template content contained in the Master Page, and then the ASP.Net Placeholder tags were stripped out and finally the server would process any other server side elements before sending the results to the client. Notice also that setting the Title parameter in our content page was still applied even though the title tag is actually outside of any of our Content Place Holders. Any code behind files (.cs or .vb) that are associated with the pages will get processed just fine. Another nice feature is that you can even specify a code behind file for your mast page that so that it can be used to insert server code that you want to get processed on every page.

Resulting generated page: Example 1

Now if we decided we did not need to change the default content that we have for the header in our HeadContent Place holder, we would just omit specifying a corresponding asp:Content tag in our content page. If you omit a placeholder region in your page the server will then just use the default content from the master page instead, like below.

Resulting generated page: Example 2

This is especially nice if you decide to adfd a new Content Region to a template after the site has already been published. You do not have to go back and add that region to every page the uses your template. Instead you would only need to update the pages where you want to specify custom content in your new content placeholder.

This article really just scratches the surface with what can be done with master pages. However many sites do not need any more complexity then this. Nested master page will come in handy when you want to build a section of subpages, say recipes for example, that will all have a very similar look, but still inherit from the Main Master Page to inherit the site's header, footer, etc.

Posted by Mark at 14:25

Authors

Recent Comments

Powered by Disqus Error loading MacroEngine script (file: uBlogsyListBlogRoll.cshtml)