So if you’re moving your production environment, or even just adding another server to your production environment, bash scripts will be of great help to you. The reason for scripting out your deployment is simple: reproducibility. Don’t take chances migrating a live environment manually. Deployment scripts are testable and version-able.

WARNING: This isn’t a tutorial on bash-scripting. I presume you already know at least some of the basics.

The strategy of this script is simple: Setup all of the variables up front, then execute the following:

1. Checkout all code into a holding folder (servername.hold)
2. Switch to the appropriate version of code (git checkout tags/release-0.1)
3. Create any necessary folders that are not versioned (like cache and log folders)
4. Apply any necessary ownership/permissions (apache, 0700)
5. Move the folder from the holding location, to the operating location

The strategy is simple enough in fact, that you could have multiple site deployment scripts that merely setup the variables for use with the same operational script. Anyways, here’s an example of how to get this done.

#!/bin/bash

#move the files from the holding area, to the actual area
echo `mv $HOLD_LOCATION $PROD_LOCATION`


As you can see, everything from the operational section down is basically plug and play. The variables are set, and it’s off to the races. Note that the library repository is just something that’s common for what I typically deal with. That may not apply to your situation. This script shouldn’t serve as the definition of what a production deployment script should be. Rather, this is just an example of one that’s been quite helpful to me.

I’ve written since Matt and Suzanne were married, but I’ve yet to write about it. I was the best man, so I guess I’d be as good as anyone to say something about their wedding. It was a beautiful wedding. Matt and Suzanne are a great couple, and it’s been awesome to watch their relationship grow to what it is today. I’d do just about anything for those two, and I couldn’t be happier for them now.

I was promoted to Product Manager of MemberFuse lately too. If that sounds serious, it’s because it is. I’m the one in charge of the direction that product will take. I’ve recently gotten pretty hooked on what ning is doing, and I’m considering using them as a platform for MemberFuse. We’ll see if Sterling and Derek will buy into the concept, but I’d rather not re-invent the wheel.

Server problems…. Grrrrrrr……

Last Thursday, I noticed all of the sites on one of my servers were down. I tried to remote into the server, but I couldn’t. So I RDP’d to another server on that network and performed a remote restart. The only problem was, the server wouldn’t restart. I had the client ship me the server, and after a couple hours of tinkering it was apparent that someone had sabotaged the server.

That’s a long story, that I’ll probably write about later. The short version is: it’s fixed, and I’m using WordPress now. For those of you who had left comments before, they’re gone now. I’m really sorry about that :/ The client’s sites are going to take some time to get back to full capacity, but I should have the base of it done tonight.

I recommended a Windows SBS 2003 box. The client obliged.

All was fine until the issue of VPN came up. I’ve done VPN’s before, but usually it’s through hardware, not through the OS. The client eventually was paid in full, and the issue still wasn’t completely resolved. I felt terrible about it, so I made it my priority to fix. The client was really cool, and I didn’t want them to feel cheated or upset in any way.

I won’t go through the whole tutorial on how to setup an SBS box, but I will say that usually, it’s very intuitive. Well, when I set up the box, I configured it to work on one subnet. However, the modem supplied to the client wouldn’t allow GRE packets through, so they needed to get a new modem.

When that modem arrived, it didn’t work with their existing Linksys wireless router. So I used the modem as the router, and plugged the wireless box into it, and ran it as a separate subnet. Keep in mind, this was after I had already configured the SBS box for the previous subnet.

I thought I had configured the server to work with the new network settings, but I missed a couple of items.

Clear ARP cache.

Since RRAS was started, you couldn’t clear the ARP cache (the table with the addresses of machines according to the old subnet). I had to stop the RRAS service to clear the ARP cache. Keep that in mind if you have to move an SBS box from one network to another.

Change ALL network settings. When I changed the TCP/IP information for the network adapter (only one), I only changed the information on the front dialog box. Which means I forgot to change the WINS information! Since the client was using VPN so he could navigate to files on the network, that was pretty important.

Also, I needed to add the dns suffix to the DNS settings area as well.

The moral of the story, take the time to get it done right the first time.

Shadow Copy is a snapshot of a drive, at a particular moment in time. It’s comparable to incremental backups, kinda.

While Shadow Copy is not intended to replace regular backups, it’s a very handy tool to quickly find files that users lose all of the time. Note, this is only available on Windows Server machines. Your XP and Vista machines aren’t going to do this.

Heres how to use it:

First, make sure the Shadow Copy service is running in the services mmc. You’re looking for the service called ‘Volume Shadow Copy’. Make sure it’s started, and it’s set to Automatically start. Once you have that covered, you can move on.

On the server you wish to use Shadow Copy on, navigate to ‘My Computer’.

Right Click the Drive (usually ‘C:’) that you want to use Shadow Copy on.

Click Properties

Click the tab ‘Shadow Copies’

Click the enable button if it’s not grayed out. If the button is grayed out, then you’re already running Shadow Copy. We’ll assume you’re not, so at least pretend to click the enable button.

Now, click the ‘Settings’ button. You should see the following dialog box:

This is where you set the maxium size you want your shadow copy database to be. As a general rule of thumb, you should never use less than 10% of what your max storage capacity is.

You can also set how often you make Shadow Copies. Keep in mind that the more often you make a Shadow Copy, the more space you will need. The default settings are twice a day, at 7:00am, and 12:00pm. I’ve never found a reason to change this, but I’m sure some of you out there will find plenty of reasons.

Now that Shadow Copy is setup, it’s time to see it in action. Back in the first dialog box we saw , click the ‘Create Now’ button to manually create your first Shadow Copy. Don’t worry, you won’t have to do this again.

Now here’s the sort of tricky part. In order to access the shadow copies that have been created via file or folder, you have to view the folders via net connection.

You can either type in the UNC name of the server (i.e. \\YOUR-SERVER-NAME) and navigate to the folder or file you want, or you can view them over a mapped network drive

Once you do that, THEN you can right click your file, or folder, click on properties, and then click on the ‘Previous Versions’ tab.

From here, you can view a previous version, copy or restore. Usually, your best bet is to view the files you want to restore first. It doesn’t help anyone to restore old files that were wrong to begin with. Get someone else’s (think management) OK before restoring files.