Rackspace’s Cloud DNS service takes care of the heavy lifting of maintaining DNS servers and allows you to query an API to manage your DNS zones and their records. The deal is a little more sweet once you learn that the service is currently free of charge.

Writing scripts to query an API is surely convenient for automation but it might not be handy if you’re looking to make some quick adjustments to various domains. That’s why I started a small project to make a graphical interface for the Rackspace Cloud DNS service. The project contains a small Python application based on Flask, Jinja2 and python-clouddns.

All of the installation instructions and documentation is over in GitHub. As of today, you can do quite a few tasks in the interface:

•    List all of the domains in your account
•    Add and remove domains from your account
•    View and edit records under each of your DNS zones
•    All of the record types supported by the API are supported in the interface

It would be unreasonable to write a post about a graphical application without a few screenshots:

Adding a zone

Adding records to a zone

Listing records in a zone

If you find bugs or think of improvements, feel free to open an issue in the GitHub project or start a pull request.

Much of my recent work has centered on OpenStack and I’ve found myself overwhelmed by learning Python. Although I don’t have any formal education on anything related to computer science or programming, I’ve worked my way through PHP, Perl and Ruby.

Ruby seems to be the most comfortable language for me to use due to the simplicity of the syntax and the handy features provided by the standard libraries and common gems. Python always caught me as strange due to the forced indenting (I indent my code properly anyway, but it still feels weird to be forced to do so), module namespaces and the overall syntax. Things like list and generator comprehension made my head spin and I avoided Python like the plague.

All of that had to change over the past few months. I’m not an expert in Python by any means but I’ll be glad to share with you how I trekked from the depths of Ruby to the edge of Python.

Learn Python The Hard Way

Zed Shaw’s guide to learning Python has been the primary recommendation from every Python developer I’ve polled at Rackspace. It is clear, concise and accurate; however, I never did finish the HTML guide. Something would end up distracting me or I’d become discouraged by something I couldn’t understand.

That’s when I found the video course on Udemy. The video course costs $29 and comes with the PDF copy of the book. You can watch Zed work through the problems on screen via an easy-to-follow screencast. He even makes common errors on screen and runs the interpreter so you can get familiar with exceptions from common typos.

Python Documentation

If it’s in Python or the standard libraries bundled along with it, it’s in the Python documentation. There are plenty of code examples for almost all of the methods from the standard libraries on the site. It’s a good resource to bookmark while you’re learning what certain methods do and which parameters they expect. You can also ensure that your code isn’t importing modules that are deprecated.

Stack Overflow

This could draw criticism from some, but Stack Overflow is a good resource to find better ways to do things in Python. I’ve written some pretty ugly Python code only to find that I could have called a couple of methods from modules found in Python’s standard libraries. You can find lots of examples of code simplification and recommendations for which modules to use for a particular project.

Keep in mind that some suggestions on the site can be subpar. Some may contain deprecated or insecure code that could hurt your project’s success. Be sure to look through the comments after each answer to ensure that you’re reading a solid solution.

Coworkers And Colleagues

Some of the best resources for learning Python are probably all around you in your office or online. I’m extremely fortunate to be surrounded by gifted and experienced developers at Rackspace who genuinely care about their work and want to share their strategies with others. I’ve always had a tough time understanding lambdas (I couldn’t understand them in Ruby, either), but one of my coworkers took me through some examples as I was leaving work.

If you feel like you might be a bother to your coworkers, try to do some homework on the topic first or give them a specific example of what you’re trying to solve. It will show them that you’ve done your best to understand the topic but that you need some help getting over the hump. A hot cup of their favorite coffee or snack doesn’t hurt either.

Just Try It

Find a problem, make a project and write some Python. Most of us have something we’d like to accomplish if we had the time. Take that idea or problem and write Python to solve it. You’ll pick up new knowledge as you work through the project and you’ll probably back yourself into a corner more than once. When it happens, go back to the documentation, do some Googling and lean on your peers.

I’ve been working with Python for just over a month and these strategies have jump started my learning by leaps and bounds. If you’re struggling, drop me a line and I’ll see what I can do to help. I’m also eager to hear your strategies for learning Python so they can be shared with others.

My mother was always the one who told me (and her students) that everyone has a story. She said that writing could be therapeutic in ways you probably won’t consider until you’ve written something that someone else enjoys. Just as software developers exist to write software for their users, writers exist to write stories for their readers. There’s nothing that says technical people can’t become excellent writers who inspire others to learn and share their knowledge with others.

The goal of this post is to encourage technical people to enjoy writing, write efficiently and feel comfortable doing it. I’ll roll through some of the most common responses I’ve received about why technical people don’t blog about what they know.

I don’t think I’m really an expert on anything. I’m not an authority on any topic I can think of.

I’m leading off with this response because it’s the most critical to refute. If you don’t take away anything else from this post, let it be this: you don’t need to be an expert on a topic to write about it.

You can find examples of this by rolling through some of the posts on my blog. I’d consider myself to be an expert on one, maybe two topics, but I’ve written over 450 posts in the span of just over five years. I certainly didn’t write all of those about the one or two topics I know best.

Write about what you know and don’t be afraid to do a little research to become an authority on something. A great example of this was my post, entitled “Kerberos for haters.” I had almost no expertise in Kerberos. In fact, I couldn’t even configure it properly for my RHCA exam! However, I did a ton of research and began to understand how most of the pieces fit together. Many other people were just as confused and I decided to pack all of the knowledge I had about Kerberos into a blog post. Positive and negative feedback rolled in and it was obvious that my post taught some readers, inspired some others and angered a few.

What a great way to lead into the next response:

What if I say something that isn’t correct? I’ll look like an idiot in front of the whole internet!

Been there, done that. Every writer makes errors and comes up with bad assumptions at least once. Readers will call you out on your mistakes (some do it delicately while others don’t) and it’s your duty to correct your post or correct the reader. I’ve written posts with errors, and I’ve gotten a little lazy on my fact-checking from time to time. As my middle school journalism teacher always reminded me, the most important part of a mistake is what you do to clean it up and learn from it.

In short: you’ll make mistakes. As long as you’ve done your due diligence to minimize them and respond to them promptly, your readers should forgive you.

Speaking of errors:

I’m great at a command prompt but my spelling and grammar are awful. I write terribly.

This is easily fixed. If you’re one of those folks who live the do-it-yourself type of lifestyle, pick up a copy of The Elements of Style by Strunk & White. There are free PDF versions online or you can borrow one from your nearest journalist. No matter the situation you’re in, this book has details about where punctuation should and shouldn’t be, how to structure sentences and paragraphs, and how to properly cite your sources (really vital for research posts).

Hauling around a copy of an ultra-dry reference book may not be your thing. If that’s the case, find someone you know who has a knack for writing. You can usually find helpful folks in marketing or corporate communications in most big companies who will take your post and return it covered in red ink ready for corrections (thanks, Garrett!). I’ve even spotted some folks on Fiverr who will do this for as low as $5.

I’ll wrap up with the second most common response:

I don’t know who I’m writing for? What if I write about something simple and the really technical folks think I’m a noob? What if I write something crazy complex and it goes over most people’s heads?

I’ve done both of these. Most Linux system administrators worth their salt know how to add and remove iptables rules, and they’d consider it to be pretty trivial work. Would it surprise you to know that out of over 450 posts, my post about deleting a single iptables rule is in the top five most accessed posts per month? I receive just over 11 percent of my monthly hits to this post. People are either learning from it or they can’t remember how to delete the rule and they want to use the post as a quick reference. Either way, the post is valuable to many people even if I think it’s the simplest topic possible.

On the flip side, I went nuts and wrote up a complete how-to for a redundant cloud hosting configuration complete with LVS, glusterfs, MySQL on DRBD, memcached, haproxy and ldirectord. I thought it would be valuable knowledge to a few folks but that it might sail over the heads of most of my readers. Again, I was wrong. The post is constantly in the top 10 most visited posts on the blog and I’ve probably received more feedback via comments, email and IRC about that post than any other. Once again, a post I thought would be mostly useless turned into a real conversation starter.

Let’s conclude and wrap up. Keep these things in mind if you feel discouraged about writing:

•    Write about what interests you whether you’re an expert on it or not
•    Don’t be afraid to fail
•    Be responsive to your readers
•    Even if you think nobody will read your post, write it
•    Always ensure your voice shines through in your writing — this is what makes it special and appealing

The post originally appeared on Major’s blog, Racker Hacker, and with his permission we have reposted it here.

Regular users of Python’s package tools like pip or easy_install are probably familiar with the PyPi repository. It’s a one-stop-shop to learn more about available Python packages and get them installed on your server.

However, certain folks may find the need to host a local PyPi repository for their own packages. You may need it to store Python code which you don’t plan to release publicly or you may need to add proprietary patches to upstream Python packages. Regardless of the reason to have it, a local PyPi repository is relatively easy to configure.

You’ll need to start with a base directory for your PyPi repository. For this example, I chose /var/pypi. The directory structure should look something like this:

/var/pypi/simple/[package_name]/[package_tarball]

For a package like pip, you’d make a structure like this:

/var/pypi/simple/pip/pip-1.0.2.tar.gz

Once you have at least one package stored locally, it’s time to configure apache. Here’s a snippet from the virtual host I configured:

DocumentRoot /var/pypi/
ServerName pypi.example.com

Options +Indexes

RewriteEngine On
RewriteRule ^/robots.txt - [L]
RewriteRule ^/icons/.* - [L]
RewriteRule ^/index\..* - [L]

RewriteCond /var/pypi/$1 !-f
RewriteCond /var/pypi/$1 !-d
RewriteRule ^/(.*)/?$  [R,L]

The last set of rewrite directives check to see if the request refers to an existing file or directory under your document root. If it does, your server will reply with a directory listing or with the actual file to download. If the directory or file doesn’t exist, apache will send the client a redirection to the main PyPi site.

Reload your apache configuration to bring in your new changes. Let’s try to download the pip tarball from our local server in the example I mentioned above:

$ curl -I 
HTTP/1.1 200 OK

$ curl -I 
HTTP/1.1 200 OK

I’ve obviously snipped a bit of the response above, but you can see that apache is responding with 200′s since it has the directories and files that I was trying to retrieve via curl. Let’s try to get something we don’t have locally, like kombu:

$ curl -I 
HTTP/1.1 302 Found
Location: http://pypi.python.org/simple/kombu/

Our local PyPi repository doesn’t have kombu so it will refer our Python tools over to the official PyPi repository to get the listing of available package versions for kombu.

Now we need to tell pip to use our local repository. Edit ~/.pip/pip.conf and add:

[global]
index-url = 

If you’d rather use easy_install, edit ~/.pydistutils.cfg and add:

[easy_install]
index_url = 

Once your tools are configured, try installing a package you have locally and try to install one that you know you won’t have locally. You can add -v to pip install to watch it retrieve different URL’s to get the packages it needs. If you spot any peculiar behavior or unexpected redirections, double-check your mod_rewrite rules in your apache configuration and check the spelling of your directories under your document root.

I used to be one of those folks who would install Fedora, CentOS, Scientific Linux, or Red Hat and disable SELinux during the installation. It always seemed like SELinux would get in my way and keep me from getting work done.

Later on, I found that one of my servers (which I’d previously secured quite thoroughly) had some rogue processes running that were spawned through httpd. Had I actually been using SELinux in enforcing mode, those processes would have probably never even started.

If you’re trying to get started with SELinux but you’re not sure how to do it without completely disrupting your server’s workflow, these tips should help:

Get some good reporting and monitoring

Two of the most handy SELinux tools are setroubleshoot and setroubleshoot-server. If you’re running a server without X, you can use my guide for configuring setroubleshoot-server. You will receive email alerts within seconds of an AVC denial and the emails should contain tips on how to resolve the denial if the original action should be allowed. If the AVC denial caught something you didn’t expect, you’ll know about the potential security breach almost immediately.

# setenforce 0
# getenforce
Permissive

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=permissive

# getsebool -a | grep httpd
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_network_connect --> on
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> on
httpd_can_sendmail --> on
... and so on ...

# togglesebool httpd_can_network_memcache
httpd_can_network_memcache: active

# setsebool httpd_can_network_memcache on

# aureport --avc | tail -n 5
45. 01/24/2012 04:23:29 postdrop unconfined_u:system_r:httpd_t:s0 4 fifo_file getattr system_u:object_r:postfix_public_t:s0 denied 1061
46. 01/24/2012 04:23:29 postdrop unconfined_u:system_r:httpd_t:s0 2 fifo_file write system_u:object_r:postfix_public_t:s0 denied 1062
47. 01/24/2012 04:23:29 postdrop unconfined_u:system_r:httpd_t:s0 2 fifo_file open system_u:object_r:postfix_public_t:s0 denied 1062
48. 01/24/2012 14:01:58 sendmail unconfined_u:system_r:httpd_t:s0 160 process setrlimit unconfined_u:system_r:httpd_t:s0 denied 1123
49. 01/24/2012 14:01:58 postdrop unconfined_u:system_r:httpd_t:s0 4 dir search system_u:object_r:postfix_public_t:s0 denied 1124

Getting yourself ready for any type of examination is usually a stressful experience that involves procrastination and some late nights leading up to the test. Every time I take one, I always say to myself, “I’m really going to get ahead of this next time and study early. This last minute stuff is terrible.” But I always forget all of this as the next exam rolls around.

Quick note: As you read through the remainder of the post, you may wonder why some of it is a bit vague. Every Red Hat test taker is under a NDA to prevent disclosure of test information that may reduce the security of the exam itself. Penalties start with losing credit for the exams previously taken and they can escalate up to legal action. I hope you’ll understand why I’m not able to go into details about certain portions of the Red Hat examinations.

I’ve taken seven Red Hat exams already: two for the RHCE and five for the RHCA. These tests certainly aren’t easy, but there are some good guidelines and tips you can use to make your studying efforts less stressful and more productive. Without further ado, here are my recommendations for prospective Red Hat examinees:

Build a flexible study environment

This is critical. You’ll need some spare servers or some available virtual machines to practice the objectives on each exam. However, don’t feel like you need to spend the money on a Red Hat subscription to get your studying done. Most of the test objectives on the majority of exams can be completed with very similar Linux distributions, like Scientific Linux or CentOS. Look for a version of the distribution that is closest to what you’ll be tested on at exam time. Your study environment should meet some basic criteria:

•    You should be able to quickly build and tear down servers or virtual machines
•    Keep the latency to your environment low to avoid getting frustrated
•    Use applications like VirtualBox, VMWare Fusion/Workstation to practice on your own computer
•    Consider using VMs from cloud providers if you’re under a time crunch

Some exams may require some bare-metal access to the server itself (especially EX442), so keep that in mind when you’re looking for a good practice environment. You may need some specific network or storage setups for some exams (as with EX436). If you’re not sure what you need, be sure to ask your instructor or someone else you know who has taken the exam already.

Prioritize doing over reading

The Red Hat exams are all hands-on, practical exams. You won’t find any essays or multiple-choice questions in these exams. Although the materials from Red Hat are full of good information, reading this information can only get you so far. You need to practice setting up the services on your own to be fully prepared for the test. If you’re not pressed for time, reading through the book can give you some details about the lab sequences, which you might miss by solely reading through labs themselves.

Research the why, not the what, to remember

This is especially important for the RHCA exam track. You may find that there is a ton of material to cover for the exam and that it’s difficult to remember each command to bring a certain service online or to repair a problem. Instead of thinking through the problem as “first, I do this, then I do this”, try to understand why each step is important in the first place.

Here’s a good example. I’ll be the first one to admit that Kerberos drives me crazy. I’ve even written posts about it. The commands seemed really archaic, the daemons didn’t make sense, and the lack of readline support in the Kerberos tools made me want to throw my computer out the window (come on, MIT!). I put my class materials aside, went to Google in a browser, and started researching Kerberos.

I read some of MIT’s documentation, ventured over to Wikipedia, and poked at some of the documentation within the Kerberos RPM packages. After a while, I began to realize how it all fit together. “Okay,” I thought to myself, “I need principals in a keytab to do these things, but I need to have a database for the admin stuff first.” Suddenly, the order of things in my head wasn’t just memorized any longer. The process of operations seemed to make logical sense because I fully understood how the pieces of a Kerberos infrastructure fit together.

If you start to get discouraged, take a break and learn more about why you’re doing what you’re doing. Once it becomes second nature, working through the problems on the exam becomes much easier.

Lean on your available resources

Don’t forget that there are other knowledgeable folks available to talk to when you get bogged down. Lean on other RHCE’s, RHCA’s, or experienced Linux users to get the answers or explanations you need. If you already have a Red Hat certification, head over to the Red Hat Certification Forums and meet up with other examinees that are discussing test preparation.

Also, you’ll find some knowledgeable (but sometimes snarky or quirky) people on IRC who are eager to point you in the right direction. Try the #rhel, #centos, or #fedora channels if you’re struggling through the configuration of a certain service. Many Linux users may roll their eyes about it, but Twitter is also a pretty good way to reach out to people who have a lot of Linux experience.

Summary

Remember to lean on the knowledge of others, get hands-on with the test objectives and do your research when you’re frustrated. The exams from Red Hat are generally difficult and cover a lot of material, but with the right amount of preparation and determination you can pass the exams and get the certifications you want.

The post originally appeared on Racker Hacker, Major’s blog, and with his permission we have reposted it here.

Standard email etiquette is pretty obvious to most of us and if you’re good at it, you’ll get your point across more often without stepping on toes or causing unneeded confusion. Simple things like identifying yourself well, avoiding sarcasm and adding context to statements are all extremely beneficial. However, writing emails to highly technical developers, system administrators and engineers is a little trickier. These types of email recipients don’t really enjoy handling email (inbound or outbound) and most find that email is just a speed bump which interrupts their productivity.

If you’re not technical, you might be asking yourself: “I need to email technical people and they need to take what I say seriously? How do I do it?” It’s not impossible, but the rest of this blog post should help.

Brevity is key

You need to get your point across concisely and succinctly so that your email is seen as less of a distraction. Avoid adding a lot of context where it isn’t needed and try to summarize business needs and processes unless details are absolutely critical. If you need to send your email to multiple recipients and some of those recipients need additional details, provide an abstract at the beginning of the email.

Learn the ways of TL;DR

I’ve heard quite a few conversations like these around the office:

Nerd 1: “Did you get that email from [name here]?”
Nerd 2: “The six page one with four PDF files attached?”
Nerd 1: “Yeah. That one.”
Nerd 2: “TL;DR dude, seriously. Did you read it?”
Nerd 1: “Nah. I might read it later.”

If someone’s ever mentioned “TL;DR” (too long; didn’t read) when your email was mentioned, don’t fret. It’s a quick fix. Just add a quick summary to the top of your email prefaced with “TL;DR”. Provide a really brief summary (bulleted lists are a plus) of your email in the section and then start your email right afterwards. Here’s an example:

TL;DR
 * next software release deploys Monday
 * two bugs remaining to fix
 * we will get started at 8AM Saturday, yeaaaaah

(Missed the joke? Head over to Wikipedia.)

If one of the summary points interests a recipient, they’ll scan your email for the pertinent sections. Some recipients may only need to see what’s in the summary and they won’t bother reading the remainder. Either way, the effectiveness of your email increases by leaps and bounds.

Plain text

Users of mutt prefer plain text e-mails

If you only take away one thing from this entire post, let it be this section. Writing emails in plain text is *highly recommended* if you want a technical person to take your email seriously. Many system administrators I know use mutt, a text-based console-only email reader. Click the thumbnail at the right and imagine what your emails would look like if they’re full of images, stylesheets and background images. Better yet, imagine if your entire email was in an image and the email itself had no text.Here are a few more tips under this category:

•    Don’t use Outlook stationery.
•    Never send emails with an image as the email itself.
•    No Comic Sans at any time. Period.
•    Avoid graphical email signatures (more on that in a moment).

Email signatures

Brevity can definitely be applied to email signatures, too. How many times have you seen emails that end like this:

Frank Frankelton MCSE, RHCSA, RHCE, CCNA, RHCA, LPIC-3, Ph.D., M.D., Esq., CMDBA
Systems Adminstrator Extraordinaire, Database Administrator, All-around great guy
Office: 210-555-1212
Mobile: 210-555-1213
Other Mobile: 210-555-1214
Fax: 210-555-1215
VOIP: 210-555-1216
AIM: frankeltonia
Twitter: @frankyfrank
Jabber: frankfurter@frankeltonisinthehouse.com
Big Company, Inc

You might think that nobody would ever send out emails with a signature like the one above, but I’ve seen some that are actually worse. Keep the signature short and only put in the information that people really need to know. Generally, your name and title or department is sufficient for email signatures (unless your local/federal laws require otherwise). Always preface it with a double dash “–” on a line by itself to signify that the remainder of the email is the signature.

Summary

Keep it simple, keep it brief and keep it relevant. While the suggestions above might not apply to every business or every person, following the suggestions will increase the effectiveness of your emails and ensure that your voice is heard on the other end.

I’m really interested to hear your comments. Are there some suggestions you have that I missed in the post? Did I make some suggestions which didn’t make sense or don’t apply to you? Let me know!

Major Hayden is a DevOps engineer working on OpenStack at Rackspace and he writes posts on technology topics for his blog, Racker Hacker.  He is a contributor to Fedora and other open source projects.  You can follow @rackerhacker on Twitter for all of Major’s tweets.

Kernels are often overlooked but they’re one of the most critical pieces of software – if not the most critical piece – on a Linux system.  At Rackspace, we’ve traditionally kept this simple for you by maintaining kernels outside the instance.  More and more customers however have asked for greater control over the kernels they run.  We’ve heard you and are happy to begin introducing this capability today with our release of the Fedora 15 image.

Our new model going forward moves the kernel inside the instance.  This means you can either run the included kernel provided by your Linux distribution OR replace it with any custom kernel you build on your own.  Simplicity or control – you choose what works best for you.

This feature has several benefits:

Flexibility

By allowing you to run the kernel of your choice, you’re able to add modules and easily change kernel parameters through your distribution’s package manager and kernel tools.  If you need support for something that doesn’t exist within the kernels provided by your distribution, you can also download and compile a vanilla kernel to meet your needs.

Security

Controlling your own kernel means you choose when to install new kernels that provide additional security features or vulnerability patches.  You simply install the new kernel, update your grub configuration file and reboot when the time is right.

Stability

Using your Linux distribution’s kernel ensures the highest level of compatibility between your distribution’s applications and the kernel itself.  Many utilities and applications may require certain support from the kernel and that support may be limited to certain versions of the Linux kernel.  This additional level of stability reduces application errors, kernel panics, and memory leaks.

Simplicity

There’s no need to worry if you’re not familiar with managing your own kernels.  Your instance will have a kernel installed from the initial build and most distributions will seamlessly install newer kernels via the distribution’s package manager.  The experience will be very similar to running Linux on a bare metal server.

Going forward, we will be phasing in this feature as the default for all Rackspace Cloud Server Linux images.  Fedora 15 is the first and other new images will follow over time.  Please note that nothing changes for existing Cloud Server instances.  However, if you wish to start managing kernels on these instances, you may convert them at your convenience.  For more information on this, please visit this KB article.

Our Cloud Servers product is rapidly evolving and we’re striving to give you the stability and flexibility you demand along with the simplicity and ease of use you expect from Rackspace.  If you have additional suggestions on new features for Cloud Servers, please visit feedback.rackspacecloud.com and join our Product Feedback forum.

Here are my favorite techniques listed from most effective to least effective:

SSH key pairs

By disabling password-based authentication and requiring ssh key pairs, you reduce the chances of compromise via a brute force attack. This can also help you protect against weak account passwords since a valid private key is required to gain access to the server. However, a weak account password is still a big problem if you allow your users to use sudo.

If you’re new to using ssh keys, there are many great guides that can walk you through the process.

Firewall

Limiting the source IP addresses that can access your server on port 22 is simple and effective. However, if you travel on vacation often or your home IP address changes frequently, this may not be a convenient way to limit access. Acquiring a server with trusted access through your firewall would make this method easier to use, but you’d need to consider the security of that server as well.

The iptables rules would look something like this:

iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s 10.0.0.20
iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s 10.0.0.25
iptables -A INPUT -j DROP -p tcp --dport 22

Use a non-standard port

I’m not a big fan of security through obscurity and it doesn’t work well for ssh. If someone is simply scanning a subnet to find ssh daemons, you might not be seen the first time. However, if someone is targeting you specifically, changing the ssh port doesn’t help at all. They’ll find your ssh banner quickly and begin their attack.

If you prefer this method, simply adjust the Port configuration parameter in your sshd_config file.

Limit users and groups

If you have only certain users and groups who need ssh access to your server, setting user or group limits can help increase security. Consider a server which needs ssh access for developers and a manager. Adding this to to your sshd_config would allow only those users and groups to access your ssh daemon:

AllowGroups developers
AllowUsers jsmith pjohnson asamuels

Keep in mind that any users or groups not included in the sshd_config won’t be able to access your ssh server.

TCP wrappers

While TCP wrappers are tried and true, I consider them to be a bit old-fashioned. I’ve found that many new systems administrators may not think of TCP wrappers when they diagnose server issues and this could possibly cause delays when adjustments need to be made later.

If you’re ready to use TCP wrappers to limit ssh connections, check out Red Hat’s extensive documentation.

fail2ban and denyhosts

For those systems administrators who want to take a bit more active stance on blocking brute force attacks, there’s always fail2ban or denyhosts. Both fail2ban and denyhosts monitor your authentication logs for repeated failures, but denyhosts can only work with your ssh daemon. You can use fail2ban with other applications like web servers and FTP servers.

The only downside of using these applications is that if a valid user accidentally tries to authenticate unsuccessfully multiple times, they may be locked out for a period of time. This could be a big problem if you’re in the middle of a server emergency.

A quick search on Google will give you instructions on fail2ban configuration as well as denyhosts configuration.

Port knocking

Although port knocking is another tried and true method to prevent unauthorized access, it can be annoying to use unless you have users who are willing to jump through additional hoops. Port knocking involves a “knock” on an arbitrary port that then allows the ssh daemon to be exposed to the user who sent the original knock.

Linux Journal has a great article explaining how port knocking works and it provides some sample configurations as well.

Conclusion

The best way to secure your ssh daemon is to apply more than one of these methods to your servers. Weighing security versus convenience of access isn’t an easy task and it will be different for every environment. Regardless of the method or methods you choose, ensure that the rest of your team is comfortable with the changes and capable of adapting to them efficiently.

There are significant improvements for customers using varnish to cache data before it reaches the web server.  Fedora 14 comes with varnish 2.1.3 and it provides significant improvements to critbit, the default hashing method.  Also, you can now add logging within your VCL’s.  If you’re having trouble with a specific VCL, this can really help with your debugging efforts.  Apache also received a bump to version 2.2.16 which contains many security fixes and some enhancements for various modules, such as mod_ldap, mod_proxy, and mod_filter.

Developers will find that Fedora 14 offers support for the D programming language and GNUstep.  The python, erlang, and perl language interpreters also received updates.  If your applications depend heavily on processing images, you’ll benefit from the replacement of libjpeg with libjpeg-turbo.  On Fedora’s primary architectures, which include i686 and x86_64, you may see jpeg compression and decompression performance increase by as much as double.  The libjpeg-turbo project is also developed in a more open-source manner than libjpeg.

The best way to discover all of the new features is to spin up a Cloud Server with Fedora 14 and give it a try.  If you want to learn more about Fedora, join #fedora on Freenode IRC, or view the release notes.

Fedora 12 is considered EOL on December 2, 2010, so you won’t be able to build new instances with Fedora 12 after that point.  Of course, if you are still using Fedora 12 on an active Cloud Server, you won’t be affected by the change.