Posts Tagged ‘tips’

“If you build it, he will come.”

I hope I’m not alone as I find myself whispering those words in my head as I read them. If you’ve seen Field of Dreams*, you know that Kevin Costner mysteriously hears and sees things no one else can see, and he seems like a lunatic when he follows the instructions of his invisible guide. He builds a baseball diamond on his farm land, and famous baseball players like Shoeless Joe Jackson come to play from the afterlife. He took a risk to build something with faith that it would yield results.

It’s a lot like the way most visionaries and entrepreneurs take risks to make their marks on the world.

Taking an idea from inception to market is much like building a baseball field in the middle of your farmland. You can factor in all the “knowns” (size, shape, materials, etc.), but in the end, you have to trust that consumers will come. Faith in a product or service drives the concept forward, and second-guessing it or working at it halfheartedly can destroy its slim chance of success. As a company so keenly focused on innovation ourselves, we find that other innovators are drawn to us, and because I’ve had the unique opportunity to work with many of our extremely successful companies, I thought I’d put together a few simple questions you might ask yourself as you transition from inspiration to action:

1. Is your idea possible to execute? Will it be easy for the market to understand and adopt?
2. Are there technologies available to deliver the idea or will you need to build your own?
3. Are the resources you’re using to build the product the best you can leverage?

If you answered, “No,” to the first question, you might want to hit the drawing board to come up with a new strategy or approach as you aim to meet the unmet needs of the market. Don’t get discouraged at this point … By spending more time simplifying and clarifying your idea, you’re saving an exponentially greater amount of time that you’d waste having to redefine or reposition your product down the road. If you answered, “Yes,” move on to Question 2.

Question 2 will start setting a baseline of the amount of effort required to get your idea to a functional state. You might hang on Question 2 for a while as you learn more about available technologies or lay the groundwork for your project, but by doing so, you’ll have a more concrete estimate of the timeline you can expect. Once you feel confident and comfortable with the answers to Question 1 and Question 2, the last step you need to take is to Question 3.

Question 3 can be pretty far-reaching — people, technologies and even hardware/software. These are some of the “knowns” that I referenced earlier. Note that “the best you can leverage” is not necessarily going to be “the best available.” Startup ideas generally are equipped with startup resources. Cost, expertise and comfort are going to play a huge role in the adoption of resources.

One of the big roadblocks many budding entrepreneurs run into is that they have trouble preparing for success. Build your product with the expectation that it will be successful. Know what you can do to accommodate the spike in demand you’ll see when Oprah and Bono give you a shout-out.

SoftLayer has been successful because we did our best to answer with those three questions, and as we continue to grow and succeed, we live and breathe innovation. We’d like to think that we’re some of “the crazy ones” Apple referenced in its epic “Think Different” campaign, and we want to empower our customers to be a little crazy themselves.

-Clayton

*If you haven’t seen Field of Dreams yet, you should find a way to watch it immediately, if not sooner.

I immediately fell in love with CSS when we were introduced in late 2000. The ability to style a whole site outside the HTML was a fantastic concept and probably my first true introduction to separation of style and content. Put your words over here, and put how you display those words over there. So simple! Since then I have always been an advocate of cascading style sheets. Today’s tip will involve an effortless addition that will have your readers say, “Ooooh. That’s a clever little change.”

I find that when I read articles and blogs online, I not only read with my eyes, I scan the page with my mouse. Especially if it’s a wordy article or not styled in smaller columns, I highlight the text by clicking and dragging to help me maintain my focus. Up until recently, whenever you selected text that way in your browser, your operating system would choose the color of the background highlight. For Windows, this is generally blue. For OS X, this is whatever you’ve set your preferences to (which is light blue by default).

For those of you that use a newer version of Webkit (Chrome or Safari) or Gecko (Firefox), the site designer can determine what color to highlight your selection of text, and CSS has made it easy.

/* Webkit */
::selection {
    background: #972F2C;
    color: #FFF;
}
/* Gecko/Mozilla */
::-moz-selection {
    background: #972F2C;
    color: #FFF;
}

As of today, Webkit browsers are the only ones that support ::selection without browser prefixing. Firefox requires the -moz- prefix. Here we have set the highlight background color to “SoftLayer Red” (#972F2C) and made the text color white (#FFF). It should be noted that earlier versions of Webkit and Gecko did not support anything but the background property. There is still limited support for which CSS properties are allowed during selection. You are unable to change font-style, font-size, text-decoration and many other properties, but we can hope support for most of the properties will be available in the future.

This is pretty cool so far, but we can take it one small step further. Just like other selectors, we can apply the ::selection selector to other elements and style each one differently.

h2::selection {
    background: #B72E33;
    color: #FFF;
}
p::selection {
    background: #ACEFB2;
}
div::selection {
    background: #E4DB80;
}
span::selection {
    background: #C780E4;
    color: #FFF;
}

This produces the following:

Surprise your readers and give them some highlight goodness.

Happy coding!

-Philip

The iptables tool is one of the simplest, most powerful tools you can use to protect your server. We’ve covered port redirection, rule processing and troubleshooting in previous installments to this “Tips and Tricks” series, but what happens when iptables turns against you and locks you out of your own system?

Getting locked out of a production server can cost both time and money, so it’s worth your time to avoid this. If you follow the correct procedures, you can safeguard yourself from being firewalled off of your server. Here are seven helpful tips to help you keep your sanity and prevent you from locking yourself out.

Tip 1: Keep a safe ruleset handy.

If you are starting with a working ruleset, or even if you are trying to troubleshoot an existing ruleset, take a backup of your iptables configuration before you ever start working on it.

iptables-save > /root/iptables-safe

Then if you do something that prevents your website from working, you can quickly restore it.

iptables-restore < /root/iptables-safe

Tip 2: Create a cron script that will reload to your safe ruleset every minute during testing.

This was pointed out to my by a friend who swears by this method. Just write a quick bash script and set a cron entry that will reload it back to the safe set every minute. You'll have to test quickly, but it will keep you from getting locked out.

Tip 3: Have the IPMI KVM ready.

SoftLayer-pod servers* are equipped with some sort of remote access device. Most of them have a KVM console. You will want to have your VPN connection set up, connected and the KVM window up. You can't paste to and from the KVM, so SSH is typically easier to work with, but it will definitely cut down on the downtime if something does go wrong.

*This may not apply to servers that were originally provisioned under another company name.

Tip 4: Try to avoid generic rules.

The more criteria you specify in the rule, the less chance you will have of locking yourself out. I would liken this to a pie. A specific rule is a very thin slice of the pie.

iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -d 123.123.123.123 -j DROP

But if you block port 22 from any to any, it's a very large slice.

iptables -A INPUT -p tcp --dport 22 -j DROP

There are plenty of ways that you can be more specific. For example, using "-i eth0" will limit the processing to a single NIC in your server. This way, it will not apply the rule to eth1.

Tip 5: Whitelist your IP address at the top of your ruleset.

This may make testing more difficult unless you have a secondary offsite test server, but this is a very effective method of not getting locked out.

iptables -I INPUT -s <your IP> -j ACCEPT

You need to put this as the FIRST rule in order for it to work properly ("-I" inserts it as the first rule, whereas "-A" appends it to the end of the list).

Tip 6: Know and understand all of the rules in your current configuration.

Not making the mistake in the first place is half the battle. If you understand the inner workings behind your iptables ruleset, it will make your life easier. Draw a flow chart if you must.

Tip 7: Understand the way that iptables processes rules.

Remember, the rules start at the top of the chain and go down, unless specified otherwise. Crack open the iptables man page and learn about the options you are using.

-Mark

This guest blog features Fruition, a featured member of the SoftLayer Technology Partners Marketplace. Fruition’s SEO and SEM reporting web app provides highly accurate reports on search engine rankings and onsite signals that impact your Google and Bing rankings. In the video below, learn a little more about Fruition (and a few key SEO/SEM tips for small businesses) from Fruition’s Brad Anderson, and scroll down to read about SEO Goals and Key Indicators.

SEO Goals and Key Indicators

Google’s Feb 2012 Update

Between February 25-28th Google rolled out another big set of changes to their algorithm. These changes knocked down a lot of short cuts that SEO companies were using, including blog networks. The red flags have been there for a long time. Blog networks are easy to uncover simply because of the complexity of trying to setup a truly diverse hosting environment. It is not just separate C-class IP addresses it is also registrars, DNS, admin login IP addresses, plug-in profiles, etc. There are so many easy ways to group sites as being related or identical that it is not worth the effort of trying to take short cuts with your linking. Instead focus on what is going to have a lasting impact on your SEO:

• Page Speed – Improve your code, increase your hardware, etc.
• Better Onsite Content
• Usability

These three factors will have a lasting impact on your SEO during 2012 and beyond.

Get Your Strategy Together

Successful internet marketing campaigns have one thing in common: Comprehensive strategies. Today’s marketplace makes it extremely difficult to compete in one area of internet marketing without complimenting that work in several other areas. For example, why invest in search engine optimization if you don’t have a quality website to convert the traffic to leads or sales? Why invest in a mobile app if you aren’t going to optimize the listing to generate a high volume of downloads? These examples show how a comprehensive strategy to internet marketing is the best approach for future success.

Fruition.net has been successful in this comprehensive approach by staying at the forefront of each individual strategy. At the core of these strategies is a collection of goals and key indicators we use to monitor, adjust, and track performance. Below you will find a few of the most important goals for each area of internet marketing.

Comprehensive Internet Marketing Strategies

Search Engine Optimization
Search Engine Optimization (SEO) is the process of optimizing your website with the end goal of improving your ranking on the major search engines. Here are the goals and key indicators you should be tracking to evaluate the success of your SEO campaign:

Read Frution’s Tips for SEO/SEM Domination »

Shelves of books have been written about providing great customer support, but I haven’t seen many written about how to get great customer support. Lance wrote a quick guide called “The 8 Keys to Successful Tickets” in May 2007, but because there have been over 730 blog posts between that post and this post, I thought I might take a shot at the topic again without stealing too many of his ideas. When you work with a service-based company, you’re probably going to interact with customer support representatives regularly. During these interactions, your experience will not be defined by your question or the issue you have. Instead, it will be defined by how you present your issue.

It can be extremely frustrating when a server goes down or a script isn’t working the way it should. When something like this happens, my gut reaction is to get upset and throw my keyboard. I’ve also noticed that when I am angry, I have a difficult time trying to explain my problem to technical support. I know I’m not alone in that regard, so I tried to pinpoint the most important points to remember when contacting customer support. While some of the explanations below are more SoftLayer-specific, each of the tips below can be used in any situation where you need customer support.

• Remember there’s a human on the other end. It doesn’t matter where the customer support representative is; they’re human, and their responsibility is to help you. I don’t have any empirical data, but human nature tells me it’s easier to be nice to someone who is nice to you. Once you realize there’s a person on the other end of the phone trying to do his/her job, it’s a little easier to thank them in advance for their help. It may seem insignificant, but if you thank me in advance for my help, I’ll subconsciously work harder in an effort to deserve that gratitude.
• Don’t assume your request will be ignored. I’m surprised by the number of people who start or end their e-mail with, “No one will probably see this, but …” or “Not that anyone cares, but …” Don’t assume that you’ll be ignored. That assumption just creates overarching negative tone; it isn’t a “reverse psychology” play. The support process can be defined by the expectations you set for it, so get started on the right foot and expect that your questions will be answered and issues will be resolved.
• Don’t start with a threat. “If you don’t do this, I’m going to report this to my bank and other authorities,” or “If you don’t respond within 25 seconds, you’ll be hearing from my lawyer.” It’s not uncommon to hear things like this in the first message in a ticket. It’s much easier to help someone who seems easy to help. Invoking lawyers does not make your ticket seem easy to address.
• Provide useful, descriptive and relevant information. This tip can be tough since it’s hard to understand what information is “relevant,” but think about it before you send a support request. If you are having trouble logging in, then “I can’t log in. Any ideas?” is not quite as clear as “Whenever I try to log in, the login screen just reloads without an error message. I know my username and password are correct. Any ideas? Thanks.” That extra information will help considerably and will reduce the number of back-and-forth e-mails between you and the support representative.
• Don’t write overly detailed, wordy support requests. The longer your e-mail, the more difficult it is to read, diagnose and to respond. A representative has to read the entire ticket to find what’s meaningful and figure out exactly what’s wrong. Since they’re trying to help you, you want to reduce their burden. You want to make it as easy as possible for them to help you. So, be clear, concise and brief. If you’ve got a couple different issues for support to look at, break them out into individual tickets. Different issues may need to be addressed by different departments, so multiple issues in a single ticket can lead to delays in responding to specific issues in the ticket.
• More Tickets ≠ More Support. The flip-side of the above recommendation is that you shouldn’t create multiple support tickets for a single issue. While it seems like you’re drawing more attention to the issue and creating a sense of urgency, you’re really slowing down the support process. Support representatives might be addressing the same issue in parallel or information might be lost between tickets, elongating the time to resolution.
• Escalate your tickets smartly. If you think a ticket should be handled differently or if you would like a supervisor to look into a specific issue, you should always feel free to request escalation to a manager or a supervisor. The best way to make that request is to update your open ticket, initiate a live chat or place a call into the technical support phone line. If you aren’t satisfied with your support experience, then we aren’t either, so we want to hear from you.

As you can see, the prescription is not too complicated: Prepare yourself to receive the best support and help us provide the best support, and you’re much more likely to receive it.

-@khazard

I was working on my server the other night, and I found myself needing to get sound from my Windows 2008 box through an RDP (Remote Desktop Protocol) connection. Because we have a huge customer base with Windows 2008 installed now, I figured there may be someone else out there that would like to be able to hear sounds from their server on their local computer when connected, so I put together a quick walkthrough with how I got it to work:

Configuring Your Server

1. Open Windows Services (Start -> Run -> Services.msc)
2. Change the properties of the Windows Audio Endpoint Service and Windows Audio Service to “Automatic”. If the services are not already started, you can manually start them at this time.
3. Open Terminal Services ( Start -> Run -> tsconfig.msc)
4. Right-click on the RDP-TCP connection and bring up its properties. Go to the “Client Settings” and make sure that on “Redirection Audio” is not disabled.
5. Fully log out and log back into the RDP connection to the server. You will see a balloon error on your speaker icon that states “No Audio Output Device is installed.”

Making Registry Changes

1. You will now need to back up your registry and some registry changes.
2. I want to reiterate the instruction to back up your registry … As with most technical guides/walkthroughs, SoftLayer will not be held liable for any corruptions that may result from you attempting these changes. The next two steps will show how to quickly back up your registry.
3. Log into your server on an account with Administrator rights, and open regedit (Start -> Run -> regedit)
4. Export the current registry (from the “File” menu) and copy it to a location off of your server so you have it backed up.
5. Locate the following key: HKEY_CLASSES_ROOT\AudioEngine\AudioProcessingObjects. This will contain several subkeys all each named with a GUID.
6. Click on each subkey, then right-click and select “Permissions.” You will then click on the “Advanced” button and the “Owner” tab. The current owner should be listed as “TrustedInstaller.”
7. Select the Administrative account and/or group from the list and click “OK” to change the ownership.
8. Select the account you just chose and give it “Full Control,” then click “OK.”
9. In the “Detail” box of each subkey, double-click on the DWORD value “MinOutputConnections” and change it from 1 to 0, then click “OK.”
10. Once you have done this for each subkey in HKEY_CLASSES_ROOT\AudioEngine\AudioProcessingObjects, you can close regedit and restart the Windows Audio and Windows Audio Endpoint services.

Configuring Your RDP Client

Now that you have everything ready on the server, you just need to make sure your RDP client recognizes the audio. Log off of the server so you can configure your RDP client. Open RDP, go to the “Options” menu, and under “Local Resources,” select “Configure Remote Audio Settings.” Select “Play on this Computer,” and hit “OK.” Voila! You now should be able to hear sound from your Windows 2008 RDP connection.

-Bill

One of the most time consuming tasks with iptables is troubleshooting a problematic ruleset. That will not change no matter how much experience you have with it. However, with the right mindset, this task becomes considerably easier.

If you missed my last installment about iptables rule processing, here’s a crash course:

1. The rules start at the top, and proceed down, one by one unless otherwise directed.
2. A rule must match exactly.
3. Once iptables has accepted, rejected, or dropped a packet, it will not process any further rules on it.

There are essentially two things that you will be troubleshooting with iptables … Either it’s not accepting traffic and it should be OR it’s accepting traffic and it shouldn’t be. If the server is intermittently blocking or accepting traffic, that may take some additional troubleshooting, and it may not even be related to iptables.

Keep in mind what you are looking for, and don’t jump to any conclusions. Troubleshooting iptables takes patience and time, and there shouldn’t be any guesswork involved. If you have a configuration of 800 rules, you should expect to need to look through every single rule until you find the rule that is causing your problems.

Before you begin troubleshooting, you first need to know some information about the traffic:

1. What is the source IP address or range that is having difficulty connecting?
2. What is the destination IP address or website IP?
3. What is the port or port range affected, or what type of traffic is it (TCP, ICMP, etc.)?
4. Is it supposed to be accepted or blocked?

Those bits of information should be all you need to begin troubleshooting a buggy ruleset, except in some rare cases that are outside the scope of this article.

Here are some things to keep in mind (especially if you did not program every rule by hand):

• iptables has three built in chains. These are for INPUT – the traffic coming in to the server, OUTPUT – the traffic coming out of the server, and FORWARD – traffic that is not destined to or coming from the server (usually only used when iptable is acting as a firewall for other servers). You will start your troubleshooting at the top of one of these three chains, depending on the type of traffic.
• The “target” is the action that is taken when the rule matches. This may be another custom chain, so if you see a rule with another chain as the target that matches exactly, be sure to step through every rule in that chain as well. In the following example, you will see the BLACKLIST2 sub-chain that applies to traffic on port 80. If traffic comes through on port 80, it will be diverted to this other chain.
• The RETURN target indicates that you should return to the parent chain. If you see a rule that matches with a RETURN target, stop all your troubleshooting on the current chain, and return the rule directly after the rule that referenced the custom chain.
• If there are no matching rules, the chain policy is applied.
• There may be rules in the “nat,” “mangle” or “raw” tables that are blocking or diverting your traffic. Typically, all the rules will be in the “filter” table, but you might run into situations where this is not the case. Try running this to check: iptables -t mangle -nL ; iptables -t nat -nL ; iptables -t raw -nL
• Be cognisant of the policy. If the policy is ACCEPT, all traffic that does not match a rule will be accepted. Conversely, if the policy is DROP or REJECT, all traffic that does not match a rule will be blocked.
• My goal with this article is to introduce you to the algorithm by which you can troubleshoot a more complex ruleset. It is intentionally left simple, but you should still follow through even when the answer may be obvious.

Here is an example ruleset that I will be using for an example:

Chain INPUT (policy DROP)
target prot opt source destination
BLACKLIST2 tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:50
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:1010

Chain BLACKLIST2 (1 references)
target prot opt source destination
REJECT * -- 123.123.123.123 0.0.0.0/0
REJECT * -- 45.34.234.234 0.0.0.0/0
ACCEPT * -- 0.0.0.0/0 0.0.0.0/0

Here is the problem: Your server is accepting SSH traffic to anyone, and you wish to only allow SSH to your IP – 111.111.111.111. We know that this is inbound traffic, so this will affect the INPUT chain.

We are looking for:

Step 1: The first rule denotes any source IP and and destination IP on destination port 80. Since this is regarding port 22, this rule does not match, so we’ll continue to the next rule. If the traffic here was on port 80, it would invoke the BLACKLIST2 sub chain.
Step 2: The second rule denotes any source IP and any destination IP on destination port 50. Since this is regarding port 22, this rule does not match, so let’s continue on.
Step 3: The third rule denotes any source IP and any destination IP on destination port 53. Since this is regarding port 22, this rule does not match, so let’s continue on.
Step 4: The fourth rule denotes any source IP and any destination IP on destination port 22. Since this is regarding port 22, this rule matches exactly. The target ACCEPT is applied to the traffic. We found the problem, and now we need to construct a solution. I will be showing you the Redhat method of doing this.

Do this to save the running ruleset as a file:

iptables-save > current-iptables-rules

Then edit the current-iptables-rules file in your favorite editor, and find the rule that looks like this:

-A INPUT -p tcp --dport 22 -j ACCEPT

Then you can modify this to only apply to your IP address (the source, or “-s“, IP address).

-A INPUT -p tcp -s 111.111.111.111 --dport 22 -j ACCEPT

Once you have this line, you will need to load the iptables configuration from this file for testing.

iptables-restore < current-iptables-rules

Don’t directly edit the /etc/sysconfig/iptables file as this might lock you out of your server. It is good practice to test a configuration before saving to the system configuration files. This way, if you do get locked out, you can reboot your server and it will be working. The ruleset should look like this now:

Chain INPUT (policy DROP)
target prot opt source destination
BLACKLIST2 tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:50
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT tcp -- 111.111.111.111 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:1010

Chain BLACKLIST2 (1 references)
target prot opt source destination
REJECT * -- 123.123.123.123 0.0.0.0/0
REJECT * -- 45.34.234.234 0.0.0.0/0
ACCEPT * -- 0.0.0.0/0 0.0.0.0/0

The policy of “DROP” will now block any other connection on port 22. Remember, the rule must match exactly, so the rule on port 22 now *ONLY* applies if the IP address is 111.111.111.111.

Once you have confirmed that the rule is behaving properly (be sure to test from another IP address to confirm that you are not able to connect), you can write the system configuration:

service iptables save

If this troubleshooting sounds boring and repetitive, you are right. However, this is the secret to solid iptables troubleshooting. As I said earlier, there is no guesswork involved. Just take it step by step, make sure the rule matches exactly, and follow it through till you find the rule that is causing the problem. This method may not be fast, but it’s reliable. You’ll look like an expert in no time.

-Mark

It’s a new year, and though only real change between on January 1 is the last digit in the year, that change presents a blank canvas for the year. In the past, I haven’t really made New Year’s resolutions, but because some old Mayan calendar says this is my last chance, I thought I’d take advantage of it. In reality, being inspired to do anything that promotes positive change is great, so in the spirit of New Year’s improvements, I thought I’d take a look at what hosting customers might want to make resolutions to do in 2012.

What in your work/hosting life would you like to change? It’s easy to ignore or look past small goals and improvements we can make on a daily basis, so let’s take advantage of the “clean slate” 2012 provides us to be intentional about making life easier. A few small changes can mean the difference between a great day in the office or a frantic overnight coffee binge (which we all know is so great for your health). Because these changes are relatively insignificant, you might not recognize anything in particular that needs to change right off the bat. You might want to answer a daunting question like, “What should you do to improve your work flow or reduce work related stress?” Luckily, any large goals like that can be broken down into smaller pieces that are much easier to manage.

Enough with the theoretical … let’s talk practical. In 2012, your hosting-related New Year’s resolutions should revolve around innovation, conservation, security and redundancy.

Innovation

When it comes to hosting, a customer’s experience and satisfaction is the most important focus of a successful business. There’s an old cliche that says, “If you always do what you’ve always done, you’ll always get what you’ve always gotten,” and that’s absolutely correct when it comes to building your business in the new year. What can you change or automate to make your business better? Are you intentionally “thinking outside the box?”

Conservation

The idea of “conservation” and “green hosting” has been written off as a marketing gimmick in the world of hosting, but there’s something to be said for looking at your utilization from that perspective. We could talk about the environmental impact of hosting, and finding a host that is intentional about finding greener ways to do business, but if you’re renting a server, you might feel a little disconnected from that process. When you’re looking at your infrastructure in the New Year, determine whether your infrastructure is being used efficiently by your workload. Are there tools you can take advantage of to track your infrastructure’s performance? Are you able to make changes quickly if/when you find inefficiencies?

Security

Another huge IT-related resolution you should make would be around security. Keeping your system tight and locked up can get forgotten when you’re pushing development changes or optimizing your networking, so the beginning of the year is a great time to address any possible flaws in your security. Try to start with simple changes in your normal security practices … Make sure your operating systems and software packages are regularly patched. Keep a strict password policy that requires regular password updates. Run system log checks regularly. Reevaluate your system firewall or ACL lists.

All of these safety nets may be set up, but they may not be functioning at their best. Even precautions as simple as locking your client or workstation when not in use can help stop attacks from local risks and prying eyes … And this practice is very important if you keep system backups on the same workstations that you use. Imagine if someone local to your workstation or client was able to retrieve your backup file and restore it … Your security measures would effectively be completely nullified.

Redundancy

Speaking of backups, when was your most recent backup? When is your next backup? How long would it take you to restore your site and/or data if your current server(s) were to disappear from the face of the Earth? These questions are easy to shrug off when you don’t need to answer them, but by the time you do need to answer them, it’s already too late. Create a backup and disaster recovery plan. Today. And automate it so you won’t have the ability to forget to execute on it.

Make your objectives clear, and set calendar reminders throughout the year to confirm that you’re executing on your goals. If some of these tasks are very daunting or difficult to implement in your current setup, don’t get discouraged … Set small goals and chip away at the bigger objective. Progress over time will speak for itself. Doing nothing won’t get you anywhere

Happy New Year!

-Jonathan

The value of our cloud options here at SoftLayer have never been more noticeable than during the holiday seasons. Such a hectic time of the year can cause a lot of stress … Stress that can lead to human error on some of your most important projects, data and memories. Such a loss could result in weeks or even years of valuable time and memories gone.

In the past few months, I’ve gone through two major data-related incidents that I was prepared for, and I can’t imagine what I would have done if I didn’t have some kind of backups in place. In one instance, my backups were not very current, so I ended up losing two weeks worth of work and data, but every now and then, you hear horror stories of people losing (or having to pay a lot to restore) all of their data. The saddest part about the data loss is that it’s so easily preventable these days with prevalent backup storage platforms. For example, SoftLayer’s CloudLayer Storage is a reliable, inexpensive place to keep all of your valuable data so you’re not up a creek if you corrupt/lose your local versions somehow (like dropping a camera, issuing an incorrect syntax command or simply putting a thumb-drive though the washer).

That last “theoretical” example was in fact was one of the “incidents” I dealt with recently. A very important USB thumb-drive that I keep with me at all times was lost to the evil water machine! Because the security of the data was very important to me, I made sure to keep the drive encrypted in case of loss or theft, but the frequency of my backup schedule was the crack in my otherwise well thought data security and redundancy plan. A thumb drive is probably one of the best examples of items that need an automatic system or ritual to ensure data concurrency. This is a device we carry on us at all times, so it sees many changes in data. If this data is not properly updated in a central (secure and redundant) location, then all of our other efforts to take care of that data are wasted.

My the problem with my “Angel” (the name of the now-washed USB drive) was related to concurrency rather than security, and looking back at my mistake, I see how “The Cloud” would have served as a platform to better improve the way I was protecting my data with both of those point in mind. And that’s why my new backups-in-the-cloud practices let me sleep a little more soundly these days.

If you’re venturing out to fight the crowds of last-minute holiday shoppers or if you’re just enjoying the sights and sounds of the season, be sure your memories and keepsake digital property are part of a well designed SRCD (secure, redundant and concurrent data) structure. Here are a few best practices to keep in mind when setting up your system:

• Create a frequent back-up schedule
• Use at least two physically separate devices
• Follow your back-up schedule strictly
• Automate everything you can for when you forget to execute on the previous bullet*

*I’ve used a few different programs (both proprietary and non-proprietary) that allow an automatic back-up to be performed when you plug your “on the go” device into your computer.

I’ll keep an eye out for iPhone, Android and Blackberry apps that will allow for automatic transfers to a central location, and I’ll put together a fresh blog with some ideas when I find anything interesting and worth your attention.

Have a happy Holidays!

- Jonathan

Having worked in SoftLayer’s technical support department for a few years now, I can tell you that the more information you provide us, the faster we can get you to a resolution. If you can show us exactly the problem you’re seeing with details from when you see it, it’s much easier for us to troubleshoot, so I wanted to post a quick blog on the heels of Todd’s “Global Network: The Proof is in the Traceroute” post to help you get information to us much more easily.

Document Format
Many people consider a Microsoft Word document the lowest common denominator when it comes to formatting an attachment or file while others prefer plain text for everything. I always advocate the use of plain text. Plain text is universally accessible, it doesn’t require a third-party application to view, it doesn’t add funky encoding, and it uses monospaced fonts that format the text like you’d see in a command prompt if you were sharing troubleshooting results from ping and traceroute commands. It’s quite unnecessary to take a screen capture of a ping or traceroute when you run it, and it’s doubly unnecessary to paste that screen capture into a Microsoft Word document.

Copying Your Ping/Traceroute
The problem many Windows users run into is that it’s not very clear how to copy text from the command prompt … The familiar keyboard shortcuts for copying (CTRL+C) and pasting (CTRL+V) don’t work from the DOS Prompt, so the screen capture route is usually the easiest to execute. There is an easy way to copy, though.

Microsoft documented the instructions you need, and I wanted to share them with SoftLayer customers here:

1. Open the command prompt. If you’re unsure how to do this, open the Start Menu, click Run, enter “cmd” (without the quotes) and click OK.
2. Execute your command. Use “tracert softlayer.com” to follow along with this test.
3. Right-click the title bar of the command prompt window, point to Edit, and then click Mark.
4. Click the beginning of the text you want to copy.
5. Press and hold down the SHIFT key, and then click the end of the text you want to copy (or you can click and drag the cursor to select the text).
6. Right-click the title bar, point to Edit, and then click Copy.

Now the text is in the clipboard. You can paste it anywhere, including the body of a ticket. To preserve layout, I usually paste the text in Notepad and attach that file to the ticket. If you don’t want to go through the hassle of opening Notepad, just paste the results into the comment field below.

If you enjoy reading quick tips like this one that can make life easier, be sure to check out KnowledgeLayer.

-Lyndell

Bonus tip: If you want to submit your traceroute in a comment on this blog without losing the mono-spaced formatting, surround the pasted content with the <code> and </code> tags.