Posts Tagged 'Learn'

May 4, 2012

From "Computer Guy" to SoftLayer Server Build Technician

As I sat down to brainstorm ideas for this blog, I began to think about where I was when I started a few years ago and where I am now. When I was hired, I knew next to nothing about the inner-workings of data center IT. I was just your average computer nerd, or "the computer guy" as I became known around the house and to my friends. I had plenty of experience with hardware, but I had no clue just how deep the IT rabbit hole went ... I jumped in anyway.

Before I give you an example of one of the challenges I had to tackle early on, I should back up and explain a pretty important observation I had about SoftLayer: Despite how cheesy it may sound, SoftLayer is a family. If you are willing to learn and have a good work ethic, SoftLayer will to take you under its wing, and the sky is the limit. I was willing to learn, and I'd like to think I have a good work ethic, so I took on a pretty ambitious task: Learn Linux.

As a Server Build Technician — the physical "hands and eyes" in a data center — you can't get by without an intimate knowledge of Linux. As it turns out, trying to learn everything there is to know about Linux is sort of like saying "Get to the end of the Internet." Even after a few years of working with Linux, I still learn new things almost daily, and I'm sure that I'll continue to learn as long as I'm surrounded by Linux servers and other brilliant technicians who can share their Linux expertise. I could probably write a whole series of blog posts about all of the crazy things I've seen Linux servers do, but I'll focus on this "intro" blog first. Since starting with SoftLayer, my tenuous grasp of Linux was strengthened and eventually validated by my Linux+ certification!

That's only one little example of the kind of environment SoftLayer creates, and I could share dozens more.

When SLayers are treated like individuals rather than "employees," the culture is different. Managers and supervisors LISTEN to your problems/frustrations and are quick to offer their help and advice. I can feel comfortable to express personal issues with anyone in management, and I've had a handful of heartfelt talks with higher-ups that I would never dreamed of having at previous jobs. As a result, I'm excited when I walk into work because I feel like I get to hang out and work with friends for eight hours every day.

My coworkers and I can joke around one minute, and the next minute, we can have a serious and thoughtful conversation about how we could improve our processes or serve customers better better. Not only does that experience make for a comfortable working environment, it also creates a net of trust among coworkers. You know without a doubt that you can rely on your coworkers for anything.

I know it sounds like I'm stretching the truth (and the blog word count), but to be honest, there isn't enough room on this page to describe exactly how awesome I think the people at SoftLayer are. I've made many, many friends and roughly zero enemies. That's a pretty good ratio if you ask me. If you are even a TINY bit interested in IT, there's no better place to get your career started (or continued) than SoftLayer. There are positions for every skill set and level, and it doesn't stop there ... You aren't locked into one position or department if you find yourself more passionately drawn to another area of the business. SoftLayer encourages you to branch out and explore your career options, and if you want to move up, you're encouraged and supported by management to put forth the effort.

TL;DR If you're interested in getting into anything IT related, SoftLayer has a place for you, and as a very happy employee, I'd highly recommend taking advantage of that opportunity.


November 15, 2011

UNIX Sysadmin Boot Camp: User Management

Now that you're an expert when it comes to bash, logs, SSH, and passwords, you're probably foaming at the mouth to learn some new skills. While I can't equip you with the "nunchuck skills" or "bowhunting skills" Napoleon Dynamite reveres, I can help you learn some more important — though admittedly less exotic — user management skills in UNIX.

Root User

The root user — also known as the "super user" — has absolute control over everything on the server. Nothing is held back, nothing is restricted, and anything can be done. Only the server administrator should have this kind of access to the server, and you can see why. The root user is effectively the server's master, and the server accordingly will acquiesce to its commands.

Broad root access should be avoided for the sake of security. If a program or service needs extensive abilities that are generally reserved for the root user, it's best to grant those abilities on a narrow, as-needed basis.

Creating New Users

Because the Sysadmin Boot Camp series is geared toward server administration from a command-line point of view, that's where we'll be playing today. Tasks like user creation can be performed fairly easily in a control panel environment, but it's always a good idea to know the down-and-dirty methods as a backup.

The useradd command is used for adding users from shell. Let's start with an example and dissect the pieces:

useradd -c "admin" -d /home/username -g users\ -G admin,helpdesk -s\ /bin/bash userid

-c "admin" – This command adds a comment to the user we're creating. The comment in this case is "admin," which may be used to differentiate the user a little more clearly for better user organization.
-d /home/username – This block sets the user's home directory. The most common approach is to replace username with the username designated at the end of the command.
-g users\ – Here, we're setting the primary group for the user we're creating, which will be users.
-G admin,helpdesk – This block specifies other user groups the new user may be a part of.
-s\ /bin/bash userid – This command is in two parts. It says that the new user will use /bin/bash for its shell and that userid will be the new user's username.

Changing Passwords

Root is the only user that can change other users' passwords. The command to do this is:

passwd userid

If you are a user and want to change your own password, you would simply issue the passwd command by itself. When you execute the command, you will be prompted for a new entry. This command can also be executed by the root user to change the root password.

Deleting Users

The command for removing users is userdel, and if we were to execute the command, it might look like this:

userdel -r username

The –r designation is your choice. If you choose to include it, the command will remove the home directory of the specified user.

Where User Information is Stored

The /etc/passwd file contains all user information. If you want to look through the file one page at a time — the way you'd use /p in Windows — you can use the more command:

more /etc/passwd

Keep in mind that most of your important configuration files are going to be located in the /etc folder, commonly spoken with an "et-see" pronunciation for short. Each line in the passwd file has information on a single user. Arguments are segmented with colons, as seen in the example below:


Argument 1 – username – the user's username
Argument 2 – password – the user's password
Argument 3 – 12345 – the user's numeric ID
Argument 4 – 12345 – the user group's numeric ID
Argument 5 – "" – where either a comment or the user's full name would go
Argument 6 - /home/username – the user's home directory
Argument 7 - /bin/bash – the user's default console shell

Now that you've gotten a crash course on user management, we'll start going deeper into group management, more detailed permissions management and the way shadow file relates to the passwd usage discussed above.


October 21, 2011

Why Don't You Work Here Yet?

I started my career with SoftLayer in March 2011 as a Server Build Technician, and after a few short months, I can safely say that coming here was one of the best moves I have ever made in my life. I have worked in a number of different jobs ranging from retail to shipping, but in my heart, I always knew I wanted a career in computer technology. SoftLayer made that dream come true.

When I started, I felt a bit overwhelmed with the amount of information I had to learn all at once. That feeling quickly subsided during the first week as I realized how the work environment and culture is built on employees who take great pride both what they do and the knowledge they are able to pass on to newcomers. I knew I was in good hands. I felt like I was a part of an elite group of intelligent, inspiring, funny, energetic and down to earth people.

Through the interactions I've had with my direct coworkers, my knowledge has grown tremendously, and I feel more confident in meeting and exceeding the expectations and responsibilities in front of me. The original SoftLayer culture is alive and well thanks to the efforts and example of the management team, and it doesn't take long to notice that this company has a passion for customer service, and we strive to be the very best we can be. Because of the encouragement and optimism I have been given, I see a bright future for me here.

As our operations expand, I can't help but get excited for the success in store for the business, our team and our customers. We're ready to embrace new challenges, and though the tasks seem daunting, I know our team can handle them easily. I take great pride in my work, and I'm quick to tell the SoftLayer story to anyone who will listen. The company motto is, "Innovate or Die," and every employee – from Dallas to Amsterdam to San Jose to Singapore – lives and breathes that motto daily. We're pushing the limits of what a "hosting company" can do, and we're having a lot of fun doing it.

I feel honored to say that I am a part of the SoftLayer family, and if you're in the market for a new job for an awesome employer, you should head to SoftLayer Careers to find which of the 50+ positions you'd fit so you can join us in Dallas, Houston, San Jose, Seattle, Singapore, Amsterdam or Washington, D.C.

We are SoftLayer!


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 15, 2011

UNIX Sysadmin Boot Camp: bash

Welcome back to UNIX Sysadmin Boot Camp. You've had a few days to get some reps in accessing your server via SSH, so it's about time we add some weight to your exercise by teaching you some of the tools you will be using regularly to manage your server.

As we mentioned earlier in this series, customers with control panels from cPanel and Parallels might be tempted to rely solely on those graphical interfaces. They are much more user-friendly in terms of performing routine server administration tasks, but at some point, you might need to get down and dirty on the command line. It's almost inevitable. This is where you'll use bash commands.

Here are some of the top 10 essential commands you should get to know and remember in bash. Click any of the commands to go to its official "manual" page.

  1. man – This command provides a manual of other bash commands. Want more info on a command? Type man commandname, and you'll get more information about "commandname" than you probably wanted to know. It's extremely useful if you need a quick reference for a command, and it's often much more detailed and readable than a simple --help or --h extension.
  2. ls – This command lets you list results. I showed you an example of this above, but the amount of options that are available to you with this command are worth looking into. Using the "manual" command above, run man ls and check out the possibilities. For example, if you're in /etc, running ls -l /etc will get you a slightly more detailed list. My most commonly used list command is ls -hal. Pop quiz for you (where you can test your man skills): What does the -hal mean?
  3. cd – This command lets you change directories. Want to go to /etc/? cd /etc/ will take you there. Want to jump back a directory? cd .. does the trick.
  4. mv – This command enables you to move files and folders. The syntax is mv originalpath/to/file newpath/to/file. Simple! There are more options that you can check out with the man command.
  5. rm – This command enables you to remove a file or directory. In the same vein as the mv command, this is one of those basic commands that you just have to know. By running rm filename, you remove the "filename" file.
  6. cp – This command enables you to copy files from one place to another. Want to make a backup of a file before editing it? Run cp origfile.bla origfile.bak, and you have a backup in case your edit of origfile.bla goes horrendously wrong and makes babies cry. The syntax is simply: cp /source /destination. As with the above commands, check out the manual by running man cp for more options.
  7. tar – On its own, tar is a command to group a bunch of files together, uncompressed. These files can then be compressed into .gzip format. The command can be used for creating or extracting, so it may be a good idea to familiarize yourself with the parameters, as you may find yourself using it quite often. For a GUI equivalent, think 7-zip or WinRAR for Windows.
  8. wget – I love the simplicity of this little command. It enables you to "get" or download a target file. Yes, there are options, but all you need is a direct link to a file, and you just pull one of these: wget urlhere. Bam! That file starts downloading. Doesn't matter what kind of file it is, it's downloaded.
  9. top – This handy little binary will give you a live view of memory and CPU usage currently affecting your machine, and is useful for finding out where you need to optimize. It can also help you pinpoint what processes may be causing a slowdown or a load issue.
  10. chmod – This little sucker is vital to make your server both secure and usable, particularly when you're going to be serving for the public like you would with a web server. Combine good usage of permission and iptables, and you have a locked down server

When you understand how to use these tools, you can start to monitor and track what's actually happening on your server. The more you know about your server, the more effective and efficient you can make it. In our next installment, we'll touch on some of the most common server logs and what you can do with the information they provide.

Did I miss any of your "essential" bash commands in my top 10 list? Leave a comment below with your favorites along with a quick explanation of what they do.


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!


July 8, 2011

HostingCon, Here We Come!

On August 8, the hosting world will converge on the San Diego Convention Center for HostingCon 2011. I'd say that SoftLayer will "be there with bells on," but a better way to put it would be that we'll "be there with megaphones." There are times to blend in and participate, and there are times when you follow Winston Churchill's advice:

"If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack."

This year, SoftLayer will be Bigger, Better and Badder in the conference sessions, on the expo hall floor and at the biggest HostingCon party ever.

Conference Sessions
We're honored to have SoftLayer employees speaking in six different sessions at HostingCon 2011:

Social Media/Branding Panel
Kevin Hazard, Social Media Ninja
9:00am – Monday, August 8
Marketing + Sales Track
The Power of Innovation
Nathan Day, Chief Scientist
9:00am – Monday, August 8
Business Development Track
Build vs. Buy: The CTO's Dilemma
Duke Skarda, CTO
10:00am – Monday, August 8
Technology + Operations Track
Small Business & Big Government: Public Policy and the Hosting Industry
Suzy Fulton, General Counsel
10:00am – Monday, August 8
Business Development Track
Clearing Up the Cloud: Hosting Providers Share Strategies for Competing in a Crowded Cloud Market
George Karidis, Chief Strategy Officer
2:00pm – Tuesday, August 9
Emerging Trends Track
How the Big Buyers Look At Acquisitions
Lance Crosby, CEO
3:00pm – Tuesday, August 9
Business Development Track

Over the next few weeks, you can keep an eye on the HostingCon Blog for more information about these sessions. To kick off the fun over there, they posted a preview to my session: "Setting Cloud Expectations Before Creating Cloud Strategy"

When you're not learning from one of our SLayers in the conference sessions above, we hope you'll swing by Booth #421 in the Expo Hall to chat with our team, get some SoftLayer swag and try your hand at the infamous Server Challenge. We'll have live video coverage of all of the action at our booth, and given the geek credentials of HostingCon attendees, we're expecting record-breaking times ... so start studying and training now to give yourself the best possible chance to win the iPad 2 we're bringing for the Server Challenge Champion!

HostingCon Party
Since you've read so attentively to this point about the 'work' side of HostingCon, it's time for some 'play.' At 9pm on August 9, SoftLayer, cPanel and will hosting the biggest HostingCon Party in history. 1000 lucky attendees will come together at 4th & B for networking, food, drink and THE DAN BAND!

Attendance will be strictly limited, and you watch the tickets dwindle before the event sells out at SoftLayer customers, leave a comment on this blog or contact us via Twitter (@SoftLayer) and we'll hook you up with a promo code that comps your registration ... But remember, even if you're our best customer ever, you need a ticket to get in the door, so please register while you can!

Yes, Mr. Churchill, SoftLayer is bringing the pile driver to San Diego.


July 27, 2009

Cool Tool: find

Have you ever gotten an e-mail from your server that a particular partition is filling up? Unfortunately, the e-mails don't usually tell you where the big files are hiding.

You can determine this and many other handy things by using the Unix utility 'find'. I use the 'find' command all the time in both my work at SoftLayer and also for running some sites that I manage outside of work. Being able to find the files owned by a particular user can be handy.

The 'find' command takes as arguments various tests to run on the files and directories that it scans. Just running 'find' with no arguments is going to list out the files and directories under your current location. Real power comes from using the different switches in various combinations.

find /some/path -name "myfile*" -perm 700

This format of the command will search for items within /some/path that have names starting with the string 'myfile' and also have the permission value of 700 (rwx------).

find /some/path -type f -size +50M

Find files that are larger than 50MB. The '-type f' argument tells find to only look for files.

find /some/path -type f -size +50M -ctime -7

Find files that are larger than 50MB and that have been created in the last seven days.

find /some/path -type f -size +50M -ctime -7 -exec ls -l {} \;

The -exec tells find to run some command against each match that it finds. In this case, it is going to run an 'ls -l'. Moves, removes and even custom full scripts are doable as well.

There are many, many more arguments that are possible for 'find'. Refer to the man pages for find on your particular flavor of Unix server to see all the different options for the command. As with all shell commands, know what you are running. Given the chance 'find' will wipe out anything it can ( via -exec rm {}, for example).

July 13, 2009

What a View!

I can easily define myself as the crazy one up in the Seattle Datacenter. I like to ride dirt bikes, street bikes, go fast on the water, ride in small airplanes, I could go on and on how my co-workers (and friends/family) may think I am crazy when it comes to Adventures.

What can I say, I like a challenging experience.

One of those challenging experiences is working at SoftLayer, always preparing to be ahead of the rest in this industry, we're constantly learning new technologies and taking leaps and bounds. That is the reason why I love my job so much, we're always working with the latest and greatest, learning new stuff. Speaking of leaps and bounds, I finally did something the other day I have always wanted too. I signed up for an Advance Free Fall Skydive class and jumped out of a Cessna at 13,000 feet. Free falling at terminal speeds towards the earth, At 12,000 feet I mock pulled my parachute 3 times, so the instructors who where both holding onto me by their hands only could see I learned what to do. 6000 ft came, I locked onto my altimeter, 5500 I waived hands off to the instructors and they deployed below me, and I pulled my rip cord. That all happened in about 50 seconds after leaping out of the plane. For the next 8 minutes I saw the best view in Western Washington I have ever seen. One of the thoughts that came to my mind is the only thing to relate to how I have ever thought something was this nice, was the first time I walked into a SoftLayer Datacenter and admired how well thought out and nice it was.

I'm glad to say 19 months into this job and being part of the Operations team in Seattle, I walk in each day to the datacenter and can say the same thing day in and day out. Let's hope I can say the same thing about my second jump in a few weeks.

Subscribe to learn