Posts Tagged 'Walkthrough'

August 23, 2011

SOAP API Application Development 101

Simple Object Access Protocol (SOAP) is built on server-to-server remote procedure calls over HTTP. The data is formatted as XML; this means secure, well formatted data will be sent and received from SoftLayer's API. This may take a little more time to set up than the REST API but it can be more scalable as you programmatically interface with it. SOAP's ability to tunnel through existing protocols such as HTTP and innate ability to work in an object-oriented structure make it an excellent choice for interaction with the SoftLayer API.

This post gets pretty technical and detailed, so it might not appeal to our entire audience. If you've always wondered how to get started with SOAP API development, this post might be a good jumping-off point.

Before you start playing with the SoftLayer SOAP API, you will need to find your API authentication token. Go into your portal account, and click the "Manage API Access" link from the API page under the Support tab. At the bottom of the page you'll see a drop down menu for you to "Generate a new API access key" for a user. After you select a user and click the "Generate API Key" button, you will see your username and your API key. Copy this API key, as you'll need it to send commands to SoftLayer's API.

In PHP 5.0+ there are built in classes to deal with SOAP calls. This allows us to quickly create an object oriented, server side application for handling SOAP requests to SoftLayer's API. This tutorial is going to focus on PHP 5.1+ as the server side language for making SOAP function calls. If you haven’t already, you will need to install the soap client for php, here is a link with directions.

Model View Controller

Model-View-Controller or MVC is a software architecture commonly used in web development. This architecture simply provides separation between a data abstraction layer (model), the business logic (controller), and the resulting output and user interface (view). Below, I will describe each part of our MVC "hello world" web application and dissect the code so that you can understand each line.

To keep this entry a little smaller, the code snippits I reference will be posted on their own page: SOAP API Code Examples. Protip: Open the code snippit page in another window so you can seamlessly jump between this page and the code it's referencing.

The first entry on the API Code Examples page is "The Call Class," a custom class for making basic SOAP calls to SoftLayer's API. This class represents our model: The SOAP API Call. When building a model, you need to think about what properties that model has, for instance, a model of a person might have the properties: first name, height, weight, etc. Once you have properties, you need to create methods that use those properties.

Methods are verbs; they describe what a model can do. Our "person" model might have the methods: run, walk, stand, etc. Models need to be self-sustaining, that means we need to be able to set and get a property from multiple places without them getting jumbled up, so each model will have a "set" and "get" method for each of its properties. A model is a template for an object, and when you store a model in a variable you are instantiating an instance of that model, and the variable is the instantiated object.

  • Properties and Permissions
    Our model has these properties: username, password (apiKey), service, method, initialization parameters, the service's WSDL, SoftLayer's type namespace, the SOAP API client object, options for instantiating that client, and a response value. The SOAP API client object is built into php 5.1+ (take a look at the “PHP” section above), as such, our model will instantiate a SOAP API object and use it to communicate to SoftLayer's SOAP API.

    Each of our methods and properties are declared with certain permissions (protected, private, or public), these set whether or not outside functions or extended classes can have access to these properties or methods. I "set" things using the "$this" variable, $this represents the immediate class that the method belongs to. I also use the arrow operator (->), which accesses a property or method (to the right of the arrow) that belongs to $this (or anything to the left of the arrow). I gave as many of the properties default values as I could, this way when we instantiate our model we have a fully fleshed out object without much work, this comes in handy if you are instantiating many different objects at once.

  • Methods
    I like to separate my methods into 4 different groups: Constructors, Actions, Sets, and Gets:
    • Sets and Gets
      Sets and Gets simply provide a place within the model to set and get properties of that model. This is a standard of object oriented programing and provides the model with a good bit of scalability. Rather than accessing the property itself, always refer to the function that gets or sets the property. This can prevent you from accidentally changing value of the property when you are trying to access it. Lines 99 to the end of our call are where the sets and gets are located.

    • Constructors
      Constructors are methods dedicated to setting options in the model, lines 23-62 of the call model are our constructors. The beauty of these three functions is that they can be copied into any model to perform the same function, just make sure you keep to the Zend coding standards.

      First, let’s take a look at the __construct method on line 24. This is a special magic php method that always runs immediately when the model is instantiated. We don’t want to actually process anything in this method because if we want to use the default object we will not be passing any options to it, and unnecessary processing will slow response times. We pass the options in an array called Setup, notice that I am using type hinting and default parameters when declaring the function, this way I don’t have to pass anything to model when instantiating. If values were passed in the $Setup variable (which must be an array), then we will run the “setOptions” method.

      Now take a look at the setOptions method on line 31. This method will search the model for a set method which matches the option passed in the $setup variable using the built in get_class_methods function. It then passes the value and name of that option to another magic method, the __set method.

      Finally, let’s take a look at the __set and __get methods on lines 45 and 54. These methods are used to create a kind of shorthand access to properties within the model, this is called overloading. Overloading allows the controller to access properties quicker and more efficiently.

    • Actions
      Actions are the traditional verbs that I mentioned earlier; they are the “run”, “walk”, “jump”, and “climb” of our person model. We have 2 actions in our model, the response action and the createHeaders action.

      The createHeaders action creates the SOAP headers that we will pass to the SoftLayer API; this is the most complicated method in the model. Understanding how SOAP is formed and how to get the correct output from php is the key to access SoftLayer’s API. On line 77, you will see an array called Headers, this will store the headers that we are about to make so that we can easily pass them along to the API Client.

      First we will need to create the initial headers to communicate with SoftLayer’s API. This is what they should look like:

      <authenticate xsi:type="slt:authenticate" xmlns:slt="">
          <username xsi:type="xsd:string">MY_USERNAME</username>
          <apiKey xsi:type="xsd:string">MY_API_ACCESS_KEY</apiKey>
      <SoftLayer_API_METHODInitParameters xsi:type="v3:SoftLayer_API_METHODInitParameters" >
          <id xsi:type="xsd:int">INIT_PERAMETER</id>

      In order to build this we will need a few saved properties from our instantiated object: our api username, api key, the service, initialization parameters, and the SoftLayer API type namespace. The api username and key will need to be set by the controller, or you can add in yours to the model to use as a default. I will store mine in a separate file and include it in the controller, but on a production server you might want to store this info in a database and create a "user" model.

      First, we instantiate SoapVar objects for each authentication node that we need. Then we store the SoapVar objects in an array and create a new SoapVar object for the "authenticate" node. The data for the "authenticate" node is the array, and the encoding is type SOAP_ENC_OBJECT. Understanding how to nest SoapVar objects is the key to creating well formed SOAP in PHP. Finally, we instantiate a new SoapHeader object and append that to the Headers array. The second header we create and add to the Headers array is for initialization parameters. These are needed to run certain methods within SoftLayer’s API; they essentially identify objects within your account. The final command in this method (__setSoapHeaders) is the magical PHP method that saves the headers into our SoapClient object. Now take a look at how I access the method; because I have stored the SoapClient object as a property of the current class I can use the arrow operator to access methods of that class through the $_client property of our class, or the getClient() method of our class which returns the client.

      The Response method is the action which actually contacts SoftLayer’s API and sends our SOAP request. Take a look at how I tell PHP that the string stored in our $_method property is actually a method of our $_client property by adding parenthesis to the end of the $Method variable on line 71.

The view is what the user interprets, this is where we present our information and create a basic layout for the web page. Take a look at "The View" section on SOAP API Code Examples. Here I create a basic webpage layout, display output information from the controller, and create a form for sending requests to the controller. Notice that the View is a mixture of HTML and PHP, so make sure to name it view.php that way the server knows to process the php before sending it to the client.

The controller separates user interaction from business logic. It accepts information from the user and formats it for the model. It also receives information from the model and sends it to the view. Take a look at "The Controller" section on SOAP API Code Examples. I accept variables posted from the view and store them in an array to send to the model on lines 6-11. I then instantiate the $Call object with the parameters specified in the $Setup array, and store the response from the Response method as $Result in line 17 for use by the view.

Have Fun!
Although this tutorial seems to cover many different things, this just opens up the basic utilities of SoftLayer's API. You should now have a working View to enter information and see what kind of data you will receive. The first service and method you should try is the SoftLayer_Account service and the getObject method. This will return your account information. Then try the SoftLayer_Account service and the getHardware method; it will return all of the information for all of your servers. Take the IDs from those servers and try out the SoftLayer_Hardware_Server service and the getObject method with that id as the Init property.

More examples to try: SoftLayer Account, SoftLayer DNS Domain, SoftLayer Hardware Server. Once you get the hang of it, try adding Object Masks and Result Limits to your model.

Have Fun!


August 12, 2011

UNIX Sysadmin Boot Camp: An Intro to SSH

You've got a 'nix box set up. For some reason, you feel completely lost and powerless. It happens. Many a UNIX-related sob has been cried by confused and frustrated sysadmins, and it needs to stop. As a techie on the front lines of support, I've seen firsthand the issues that new and curious sysadmins seem to have. We have a lot of customers who like to dive head-first into a new environment, and we even encourage it. But there's quite a learning curve.

In my tenure at SoftLayer, I've come across a lot of customers who rely almost entirely on control panels provided by partners like cPanel and Parallels to administer their servers. While those panels simplify some fairly complex tasks to the touch of a button, we all know that one day you're going to have to get down and dirty in that SSH (Secure Shell) interface that so many UNIX server newbies fear.

I'm here to tell you that SSH can be your friend, if you treat it right. Graphical user interfaces like the ones used in control panels have been around for quite a while now, and despite the fact that we are in "the future," the raw power of a command line is still unmatched in its capabilities. It's a force to be reckoned with.

If you're accustomed to a UNIX-based interface, this may seem a little elementary, but you and I both know that as we get accustomed to something, we also tend to let those all-important "basics" slip from our minds. If you're coming from a Windows background and are new to the environment, you're in for a bit of a shell shock, no pun intended. The command line is fantastically powerful once you master it ... It just takes a little time and effort to learn.

We'll start slow and address some of the most common pain points for new sysadmins, and as we move forward, we'll tackle advanced topics. Set your brain to "absorbent," and visualize soaking up these UNIX tips like some kind of undersea, all-knowing, Yoda-like sea sponge.


SSH allows data to be exchanged securely between two networked devices, and when the "network" between your workstation and server is the Internet, the fact that it does so "securely" is significant. Before you can do any actual wielding of SSH, you're going to need to know how to find this exotic "command line" we've talked so much about.

You can use a third-party client such as PuTTY, WinSCP if your workstation is Windows-based, or if you're on Linux or Mac, you can access SSH from your terminal application: ssh user@ipaddress. Once you've gotten into your server, you'll probably want to find out where you are, so give the pwd command a try:

user@serv: ~$ pwd
user@serv: ~$

It's as easy as that. Now we know we're in the /home/user directory. Most of the time, you'll find yourself starting in your home directory. This is where you can put personal files and documents. It's kind of like "My Documents" in Windows, just on your server.

Now that you know where you are, you'll probably want to know what's in there. Take a look at these commands (extracted from a RedHat environment, but also usable in CentOS and many other distributions):

    user@serv: /usr/src $ ls    
This will give you a basic listing of the current directory.

    user@serv: /usr/src $ ls /usr/src/redhat    
This will list the contents of another specified directory.

    user@serv: /usr/src $ ls ./redhat    
Using a "relative pathname," this will perform the same action as above.

    user@serv: /usr/src $ ls redhat    
Most of the time, you'll get the same results even without the "./" at the beginning.

    user@serv: /usr/src $ cd /usr/src/redhat/    
This is an example of using the cd command to change directories to an absolute pathname.

    user@serv: /usr/src $ cd redhat    
This is an example of using the cd command to change directories to a relative pathname.

    user@serv: /usr/src/redhat $ cd /usr/src    
To move back on directory from the working directory, you can use the destination's absolute path.

    user@serv: /usr/src/redhat $ cd ..    
Or, since the desired directory is one step down, you can use two dots to move back.

You'll notice many similarities to the typical Windows DOS prompts, so it helps if you're familiar with navigating through that interface: dir, cd, cd .., cd /. Everything else on the other hand, will prove to be a bit different.

Now that you're able to access this soon-to-be-powerful-for-you tool, you need to start learning the language of the natives: bash. In our next installment, we'll take a crash course in bash, and you'll start to get comfortable navigating and manipulating content directly on your server.

Bookmark the SoftLayer Blog and come back regularly to get the latest installments in our "UNIX Sysadmin Boot Camp" series!


June 6, 2011

What I Know: Hosting & BBQ

Last week, Thomas talked about his summertime passion, and it immediately got me thinking of mine. There are two things I know in this world: Hosting and Barbeque. They may be on the opposite ends of the spectrum, but both integral parts of the SoftLayer culture.

Being Texas born and bred, I hear stories that my first baby bed was actually a refinished barrel pit, and at the tender age of 4, I started my first fire right where I used to lay my head. By the age of 7, I graduated from grilling to smoking, and by age 10, I was expected to have mastered the art of mixing fire, smoke and the perfect rub to deliver a baby back rib so tender that you have no choice but to 'slap yo mama!'

I have to admit that I am not an official member of the 3 Bars Barbeque team, but my ribs and steaks have been taken on the road to multiple parts of Texas, and they've won contests in Memphis for their fall-off-the-bone tender texture and their "mmm mmm good" flavor. I can't really divulge my award winning recipe, but I can share my cooking method used to achieve that fall off the bone rib.

You've got to understand that smoking takes time. I generally allow one hour per pound on a nice rack of baby back ribs. In SoltLayer operations terms, for a 6lb rack of ribs, that means you'd have time to register a new domain name, provision a RHEL 5 Cloud Compute Instance, provision 2 dedicated database servers (1 in Dallas and 1 in San Jose), configure the CCI as a Web server, clone the CCI once in Dallas and once in San Jose, order eVault and add a second vault for redundancy, add local load balancing to both sites, use the previously registered domain name and set up Global Load balancing between the IPs of both local load balancers, setup rsync between web servers for one website and configure MySQL replication between your two new database servers (and you'd still have just enough time to configure the eVault backup that you ordered about 5.5 hours previously).

What were we talking about again? Oh yeah, I promised a "cooking method" lesson:

1. Get Your Ribs
Everyone dresses their meat differently ... Some prefer to marinate, some don't. I find that it doesn't make much of a difference, so I usually will remove my ribs from the fridge and rinse the before setting them aside to allow them to warm to room temperature. While that's happening, I continue the rest of the process.

2. Prepare the Pit
I like to use a smoker pit grill ... You know, something this:

3 Bars BBQ

I like to use split wood logs instead of flavored charcoal & wood chips. The wood you use is up to you; I usually do either hickory or mesquite and occasionally a log or two of apple (Beware that Mesquite burns very hot and is harder to stabilize at a consistent temperature when adding more wood to the fire later). Stack and light your fuel of choice in the smoker's firebox – the only place where you will have a fire ... The only thing that belongs in the pit is the meat and the smoke generated by the firebox.

Once you get your fire started, let it burn for a while so it can stabilize. You want the pit area to stay at a constant 225F ~ 250F. If you have enough prep time, you can also soak your wood logs for a couple of hours before you start your fire. This will cause the wood to burn slower and produce a slightly stronger smoke flavor in the ribs. This will also cut down on the amount of wood you "burn" through.

3. Prepare Your Ribs
While your fire is doing its thing and creating some good smoke, you can trim and season your ribs. Trim the membrane from the underside of the rack and season the meat with a dry rub (since it's better suited for longer cook times).

4. Start Cooking
Once your pit has stabilized at the perfect temperate, it's time to add the ribs. I use a rib rack just so I don't have to flip the ribs while they're in the pit, but if you don't have a rib rack, place your ribs on the opposite side of the pit from the firebox bone side down (you have to ensure that the fire doesn't reach your precious rack of ribs. If you are not using a rib rack, you will want to flip them about an hour and a half into cooking.

5. Keep Cooking
I use the 3–2–1 method when smoking: 3 hours on grill, remove the ribs, wrap them in foil, 2 hours on the grill in foil, remove the foil, and one more hour on the grill. By the time you get to that last hour, you'll already find it difficult to flip the ribs as the meat will start falling off the bone. If your seasoning is top notch, you won't need sauce, but the last hour is the time to baste if you want a different flavor in the mix. The 3–2–1 time frame is a loose guide to follow ... You'll need to keep an eye on the ribs to make sure they are not cooking too fast and that you're keeping the flame away from the meat, and you may need to adjust times if your temperature exceeds 250F.

6. Remove the Ribs
Remove your ribs from the pit and allow them to rest for about 15 minutes before your cut them. This break will allow the juices to redistribute throughout the meat.

7. Enjoy!
No instructions necessary.

Following these rules, you'll have a great rack of ribs, and if you took time while the ribs were cooking to order and provision that solution I talked about at the top of the post, you'll have an amazing high-availability two-tier hosting solution by the time you take your first bite!


May 30, 2011

Summer Tips to Clean Your Ride

Snowy Cars

Remember this? Your car does.

Now that Memorial Day officially marks the beginning of summer and the temperature is creeping back up, it's time to take care of that neglected car that battled the cold winter and the spring rains. Outside of work, a lot of fellow SLayers are into cars ... Some show them off, others focus on making them faster. And given the fact that we are professionally obsessive about keeping our data centers clean and tidy, that obsessiveness is pretty evident in how hard we work to keep our cars clean.

Since today is a holiday in the US, I want to take a break from the down-and-dirty server stuff to give you a quick glimpse at what many SLayers are doing today: Cleaning their rides. Like a lot of the technical troubleshooting we do, it's best to stick to a particular flow of steps to cover all the bases and get the best outcome. The following steps are the ones I take to bring back the showroom-floor shine. Since the typical car detail can run anywhere from $50-$300 this is a great way to save money every month ... so you can order another server or upgrade the hardware on an existing one. :-)

What You'll Need

  • Bucket
  • Soap
  • Sponge or Microfiber or Sheepskin Glove
  • Clay Bar
  • Wax and Foam Wax Applicator
  • Quik Detailer
  • Glass Cleaner
  • Tire Shine - Optional
  • Microfiber Towels - The more the merrier
  • Beer (or beverage of choice) - Optional ... also the more the merrier
  • Bonus: Swirl Remover - If you're using a rotary buffer
  • Bonus: Finishing Polish

Note: In all steps where washing is involved, rinse first to get any loose dirt off then gently scrub and rinse off. Car should be parked in the shade to avoid water spots. All steps after clay barring MUST be done in the shade.

Step 1: Washing the Wheels
Make sure your brake rotors have cooled before hitting them with cold water, otherwise you could risk warping them. Because of the dirt and grime wheels get, I recommend using a separate bucket and sponge for this step.

Step 2: Washing the Rest of the Car / Drying
Always work from the top of the car to the bottom, and the best practice is to do one panel at a time.
Frequently rinse your sponge or glove to release the dirt it picks up.
When scrubbing the side panels, it's better to go up and down instead of side to side or in circles.
Drying panels as soon as you've rinsed them helps prevent water spots.

Step 2.1: Tire Shine (Optional)
Try to keep Tire Shine on the tires only. If you get it on the wheel, it'll just allow dirt and/or brake dust to attach to the wheel.
Don't overdo this or it will just splash back onto your car when you start driving.

Step 3: Clay Bar
Spray Quik Detailer onto surface and gently rub the clay bar from side to side.
Fold the clay bar between sprays. This keeps the clay bar surface clean.
Dry leftover Quik Detailer with a microfiber towel.

Step 3.1: Swirl Remover then Finishing Polish (optional)
Best when used with a rotary buffer at high speed.
If doing by hand, using pressure, apply in small circular motions.
Remove with a microfiber towel.

Step 4: Wax
Using either a foam wax applicator or rotary buffer on low speed, apply wax as thinly as possible, otherwise it will be harder to remove.
When the surface looks hazy, remove with a microfiber towel.

Step 5: Quik Detailer & Glass Cleaner
Use Glass Cleaner on windows and mirrors.
Quik Detail the whole car again.
These steps clear off any leftover dust from waxing as well as remove any water spots from water that may have crept out after waxing.

Step 6: That's All!
Crack open a beer and gaze at your beautiful car ... *wipe drool off of face*.

The process can take as long as several hours to complete depending on how bad your car needs a cleaning. If this process has been completed recently, you can skip Steps 3 and 4, as clay barring is only needed ~2-3 times a year and waxing every 2-3 months.

If you're like us and you love showing off your car, after it gets all dolled up, post a link to a picture of it here in the comments!


April 7, 2011

Thou Shalt Transcode

Deep in the depths of an ancient tomb of the great Abswalli, you and your team accidentally awaken the Terbshianaki ghost army. You’re disconnected from the supply caravan with the valuable resources that could not only sustain your journey but also save your team. As Zeliagh the Protesiann hunter fires his last arrow, you come to the sudden realization that continuing your quest is now hopeless. Alas, true terror was unknown before this moment as you come to the most surprising realization: The one thing you truly can't live without is your trusty server that converts one type of media into another.

Fear not great adventurer, for I, Phil of the SLAPI, have come, and I bear the gifts of empowerment, automation and integration. Freedom from the horror of your epiphany can be found in our complementary media transcoding service.
Before we can begin, some preparation is required. First, you must venture to our customer portal and create a transcoding user: Private Network->Transcoding. As you know from the use of your other SoftLayer spoils, you shan't be obligated to access this functionality from your web browser. You can summon the API wizardry bequeathed to you by coders of old in the the SLDN scroll: SoftLayer_Network_Media_Transcode_Account::createTranscodeAccount.*

*For the sake of this blog, we'll abbreviate "SoftLayer_Network_Media_Transcode_Account" as "SNMTA" from here forward ... Shortening it helps with blog formatting.

You must then construct an object to represent a SoftLayer Network Media Transcode Job, like our SoftLayer Network Media Transcode Job template object. This template object will be built with a number of properties. Your pursuit in relieving your aforementioned horror only necessitates the use of the required properties.

You will need to decide in which format the final treasure will take form. You may find this information with the SNMTA::getPresets method.

$client = SoftLayer_SoapClient::getClient('SoftLayer_Network_Media_Transcode_Account', $trandcodeAccountId, $apiUsername, $apiKey);
$transcodePresets = $client->getPresets();
    [0] => stdClass Object
            [GUID] => {9C3716B9-C931-4873-9FD1-03A17B0D3350}
            [category] => Application Specific
            [description] => MPEG2, Roku playback, 1920 x 1080, Interlaced, 29.97fps, 25Mbps, used with Component/VGA connection.
            [name] => MPEG2 - Roku - 1080i
    [1] => stdClass Object
            [GUID] => {03E81152-2A74-4FF3-BAD9-D1FF29973032}
            [category] => Application Specific
            [description] => MPEG2, Roku playback, 720 x 480, 29.97fps, 6.9Mbps, used with Component/S-Video connection.
            [name] => MPEG2 - Roku - 480i
    [2] => stdClass Object
            [GUID] => {75A264DB-7FBD-4976-A422-14FBB7950BD1}
            [category] => Application Specific
            [description] => MPEG2, Roku playback, 720 x 480, Progressive, 29.97fps, 6.9Mbps, used with Component/VGA connection.
            [name] => MPEG2 - Roku - 480p

The freedom to use this power (the more you know!) is yours, in this instance, I scrolled through let my intuition find the option which just felt right:

stdClass Object
            [GUID] => {21A33980-5D78-4010-B4EB-6EF15F5CD69F}
            [category] => Web\Flash
            [description] =>
            [name] => FLV 1296kbps 640x480 4x3 29.97fps

To decipher this language we must know the following:

  1. The GUID is the unique identifier which we will use to reference our champion
  2. The category section is used to group like presets together, this will be useful for those who's journey leads down the path of GUI creation
  3. A description of the preset, if one is available, will be listed under description
  4. name is simply a human-readable name for our preset

You are nearly ready to restore your yearned for transcoding service as the ghostly horde presses the defensive perimeter. We have but one more task of preparation: We must provide the transcoding service a file! Using your Wand of File Transference +3, or your favorite FTP client, you enter the details for your transcode FTP account found on the Transcoding page of the IMS (or of course SNMTA::getFtpAttributes) and choose the "in" directory as the destination for your source file. Lacking no other option, you may call upon Sheshura, a fairy sprite, specializing in arcane documents for a source video file: Epic Battle

The battle rages around you, as the Wahwatarian mercenaries protect your flank. The clicking of your laptop keys twist and merge in the air around your ears only to transcend into a booming chorus of "The Flight of the Valkyries" as you near transcoding Utopia. You strike:

//  Create a transcoding client
$client = SoftLayer_SoapClient::getClient('SoftLayer_Network_Media_Transcode_Job', null, $apiUsername, $apiKey);
// Define our preset GUID and filename
$presetGUID = '{95861D24-9DF5-405E-A130-A40C6637332D}';
$inputFile = '';
 * The transcoding service will append the new file extension to the output file
 * so we strip the extension here.
$outputFile = substr($inputFile, 0, strrpos($inputFile, '.'));
try {
    // Create a SoftLayer_Network_Media_Transcode_Job template object with the required properties
    $transcodeJob = new stdClass();
    $transcodeJob->transcodePresetGuid = $presetGUID;
    $transcodeJob->inputFile = "/in/$inputFile";
    $transcodeJob->outputFile = "/out/$outputFile";
    // Call createObject() with our template object as a parameter
    $result = $client->createObject($transcodeJob);
    // $result will contain a SoftLayer_Network_Media_Transcode_Job object
} catch ( Exception $e) {
    die( $e->getMessage());

If your will did not waver nor did your focus break in the face of ever-closing ghouls pounding your resolve, your treasure will be waiting. Brandish your Wand of File Transference +3, or utilize your favorite FTP client to retrieve your reward: "out/video.flv"

If the gods be with thee, your resulting file should look like this: Epic Battle (in .flv)

With your victory fresh upon the tablets of history, you can now encode to any of our supported formats. Try using the process above to convert the video to .mp4 format so your resulting file output is Epic Battle (in .mp4)!


P.S. If you're going to take off your training wheels, the second example uses "[description] => MPEG4 file, 320x240, 15fps, 256kbps for download" for the bandwidth impaired.

March 21, 2011

7 Steps to Server Migration Success

It's been a long journey: Four years ago you paid a premium for your humble domain, and things have changed a lot since then. You want to move to a newer, cheaper, nicer place, but you dread the process of collecting all of your stuff and moving it somewhere else. What's the best way to pack it up? Will it be safe during the move? What can I throw away to make this migration easier? What about your mail? You don't want to miss anything in the midst of your move. Doesn't this sound like the last time you moved to another house? The funny thing is that while all of those questions could be describing a physical move, we're actually talking about migrating web servers.

At some point, you'll have to face moving from one server to another. Hopefully it's in the same "neighborhood" or network since that will make the speed of the move a lot faster and less expensive ... especially if the neighborhood has free private network traffic and incoming bandwidth like ours </plug>! Regardless of where you're moving your data, there are seven key steps to preparing and executing a successful server migration:

1. Prepare Your DNS
When you move your site(s) to a new server, you will likely get new IP addresses. With the advent of DNS caching, once you change your IP, it can take up to seven days before the changes propagate throughout the Internet. To keep this from happening, your first step in preparing for the migration is to change your DNS record TTL (Time To Live). This value designates how long your DNS entries should be cached.

It's best to do this step several days before you plan to move. I suggest you do it at least a week in advance to cover at least 95% to 99% of your traffic. I would also change or remove any SPF records if you have any. Details:

2. Set up Your New Server
Make sure your new server has the correct operating system installed and ready and that all hardware meets your applications' specifications. Decide how you wish to provision your site's IP addresses and make note of any differences.

3. Tune Your Server
Check your file system and make sure your partitions are set up as you need them. Set up RAID if required. Most hosts will set up RAID and your partitions for you and even provide you with test results of the hardware ... At least we do </another plug>! This is also the perfect time to implement any security practices within the OS and firewall (if installed). It's important to complete these steps before you get too far because they're much easier to do without content on the server.

4. Install Base Applications
Once you verify your server configuration, set up your operating system and secure your new server, it's time to install the supporting software you plan to us. Examples include webserver, email server and database server software and any application server software. Prepare a sample web page to tests that each of the pieces of software is installed correctly to confirm functionality.

5. Begin Data Migration
Now you're ready to do an initial data migration. Due to the enormous variance in types of data, kinds of servers, amounts of data and applications, how you proceed with this step can vary dramatically. Databases might require a backup and restore process while static data may only require the use of a tool like rsync.

The best way to complete this step is to do it during off-peak times. Understand how long it'll take to move all of your data, and set aside a conservative window to complete the move.

Once the data has been migrated, you should be able to test your website application at its newly assigned IP address.

6. Move from Old to New
Now that you've extensively tested your new server, it's time to set an officical move date and time. By now, your DNS changes have taken hold (assuming you changed them a week ago), and you are ready to throw the switch on your new infrastructure. Depending on the nature and size of your site, you might want to notify users of a maintenance window since service might be temporarily interrupted in this process.

During this window, you'll complete five tasks:

  1. Take down your site on the old server. You might want to put up a maintenance page to let people know about the scheduled work being performed.
  2. Migrate database changes and / or data changes.
  3. Confirm that your site is working properly on new server via the IP address.
  4. Change your DNS records to resolve to your new IP address.
  5. Remove the server maintenance page and redirect traffic from that page to the new server.

Once these steps have been completed, the new server will have up-to-the-minute data, and all new traffic receiving the current DNS information will be sent to your new server. All traffic that has old DNS information will be sent to the old server and redirected to the new server. This allows for all traffic to be delivered to the new server regardless of what may be cached DNS.

7. Enable / Recreate Automated Site Maintenance Jobs
To complete the migration process, you should enable or recreate any automated site maintenance jobs you may have had running on the old server. At this point, you can change your TTL values back to the default, and if you disabled an SPF record, you may restore it after a few days once you are comfortable that the Internet recognizes your new IP address for your domain.

This migration framework should be considered a very high-level recommendation to facilitate most standard server migrations, so if your architecture is more complex or you have additional configuration requirements, it might not cover everything for your migration. Migrations can be daunting, but if you plan for them and take your time, your site will be up and running on a new server in no time at all. If you have problems in the migration process or have questions about how to best handle your specific migration, make sure to have a professional sysadmin on call ... So just keep SoftLayer's number handy </last SoftLayer plug>.


January 24, 2011

5 Steps to Start Using IPv6 (not IPv5)

As Kevin mentioned on Friday, we are less than 45 days from "doomsday." The IANA only has about 3% of the resources required to sustain our current way of life. 6.8 billion people with only 4.3 billion addresses in existence. It's the 2012 saga in 2011: The exhaustion of the Internet's available IP version 4 (IPv4) addresses. What are we going to do?!

Luckily, a lot of people have been hard at work to mitigate the impending Internet crisis. IP version 6 (IPv6) is on the horizon and is already supported by most modern internet enabled devices. If you're like me, the fact that we went from IPv4 to IPv6 might make you wonder, "What happened to IPv5?"

The powers that be didn't decide to rid the number system of the number five because of its mixture of curves and right angles, and it wasn't because they only wanted to use round numbers. IP version 5 (IPv5) was a work in progress and part of a family of experimental protocols by the name of ST (Internet Stream Protocol). ST and later ST-II were connection-oriented protocols that were intended to support the efficient delivery of data streams to applications that required guaranteed data throughput.

An ST packet looks very similar to its IPv4 sibling, and both use the first 8 bits to identify a version number. IPv4 uses those 8 bits to identify IPv4 packets, and ST used the same 8 bits to identify IPv5 packets. Since "version 5" was spoken for, the next iteration in IP advancement became version 6.

If you've been around the SoftLayer blog for a while, you already know a fair bit about IPv6, but you're probably wondering, "What’s next?" How do you actually start using IPv6 yourself?

1. Get a Block of IPv6 Addresses

Lucky for you, the SoftLayer platform is IPv6 ready, and we're already issuing and routing IPv6 traffic. Obtaining a block of public IPs from us is as easy as logging into the portal, pulling up the hardware page of a server and ordering a /64 block of IPv6 IPs for $4/mo per subnet ($10 if you want a portable subnet)!

For those of you that have ordered IPs from us in the past, IPv4 addresses are usually $0.50-$1.00 each. To get a /64 of public static IPv6 addresses, it’s a whopping $0.00 for the entire range. So just how many IPs is in a /64? 256? Try again. 512? Keep going. 1 Million? You’re still cold. Let's try 18.4 quintillion. For those that understand scientific notation better, that is 1.84 x 1019. If you just want to see the number written in long form, it's 18,446,744,073,709,551,616 IP addresses. That allocation should probably tide you over for a little while.

2. Make Sure Your Server is IPv6 Ready

Most current server operating systems are ready to take the IPv6 leap. This includes Windows 2003 SP1 and most Linux OSes with 2.6.x Linux kernels. We'll focus on Windows and RedHat/CentOS here.

To ready your Windows 2003 server for IPv6, do this:

  1. In Control Panel, double-click Network Connections.
  2. Right-click any local area connection, and then click Properties.
  3. Click Install.
  4. In the "Select Network Component Type" dialog box, click Protocol, then Add.
  5. In the "Select Network Protocol" dialog box, click Microsoft TCP/IP version 6, then OK.
  6. Click Close to save changes to your network connection.

Once IPv6 is installed, IIS will automatically support IPv6 on your web server. If a website was running when you installed the IPv6 stack, you must restart the IIS service before the site begins to listen for IPv6 requests. Sites that you create after you enable IPv6 automatically listen for IPv6. Windows 2008 server should have IPv6 enabled by default.

When your Windows server is ready for IPv6, you will add IPv6 addresses to the server just as you'd add IPv4 addresses ... The only difference is you will edit the properties to the Internet Protocol Version 6 (TCP/IPv6) network protocol.

To ready your RedHat/CentOS servers, do this:

  1. Using your favorite editor, edit /etc/sysconfig/network and enable NETWORKING_IPV6 by changing the "no" to a "yes."


  2. Next edit /etc/sysconfig/network-scripts/ifcfg-eth1 to add IPv6 parameters.

    Add the following to end of the file:



  3. Once you have successfully added your assigned IP addresses, you must restart networking with this command:
    [root@ipv6test /]# service network restart

Once you have completed these steps on your respective OS, you should be able to communicate over the IPv6 stack. To test, you can ping and see if it works.

3. Bind Your New IPv6 Address to Apache/IIS

Now that you have more IPv6 addresses for your server(s) than what's available to the entire world in IPv4 space, you must bind them to IIS or Apache. This is done the similarly to the way you bind IPv4 addresses.

In IIS, all IPs that have been added to the system will now be available for use in the website properties. Within Apache, you will add a few directives to ensure your web servers is listening on the IPv6 stack ... which brings us to a very important point when it comes to discussing IPv6. Due to the fact that it's full of colons (:), you can’t just write out the IP as you would a 32-bit address.

IPv6 addresses must be specified in square brackets or the optional port number could not be determined. To enable Apache to listen to both stacks on separate sockets you will need to add a new "Listen" directive:

Listen [::]:80

And for your Virtual Hosts, the will look like this:

<VirtualHost [2101:db8::a00:200f:fda7:00ea]>
DocumentRoot /www/docs/
ErrorLog logs/
TransferLog logs/

4. Add Addresses to DNS

The final step in getting up and running is to add your new IPv6 addresses to your DNS server. If you're using a IPv6 enabled DNS server, you will simply insert an 'AAAA' resource record (aka quad-A record) for your host.

5. Test Your Server's IPv6 Accessibility

While your DNS is propagating, you can still test your webserver to see if it responds to the IP you assigned by using square brackets in your browser: http://[2101:db8::a00:200f:fda7:00ea]

This test, of course, will only work if your computer is on a IPv6 network. If you are limited to IPv4, you will need sign up with a tunnel broker or switch to an ISP that offers IPv6 connectivity.

After about 24 hours, your server and new host should be ready to serve websites on the IPv6 stack.

Good luck!


Subscribe to walkthrough