I refuse to install X on servers.  Unless there is a very compelling reason (read: application depenedent), I don’t include any of the X components on a Linux install.  After all, why would a headless server need a GUI?

So when I had to install the X server packages on my Virtual Machines just to turn on time sync, I was understandably put out.  I could log into the host and modify the .vmx file for my virtual machine, sure.  But if there is a method to do it from the guest, why not do it that way?  It turns out that vmware-guestd is the key on Linux Virtual Machines.
[root@tardis ~]# /usr/sbin/vmware-guestd –cmd “vmx.set_option synctime 0 1″
This will allow you to turn on the time sync between the guest and host from the command line when you don’t have the X server components installed and don’t want to/are unable to log into your host directly to modify the .vmx file.

Tags: cli, command line, esx, sync, time, tools.syncTime, VMware, vmware-toolbox

For those not familiar with it, VMware ESX is an enterprise-level virtualization solution packed with features, high-availability clusters chief among those.  For those that do not require these extra features, VMware had made, freely available, VMware Server, which ran on a single instance on top of Windows or Linux.  ESX, on the other hand, is entirely self contained and runs on the vmkernel.  In a move that i can only imagine makes it easier to manage a single code base, VMware did away with the Server product, to be replaced by ESXi, a stripped down version of ESX.  It is great for environments where high-availabilty is not necessary.

So now that you know what VMware ESX and ESXi are, let’s get on with it.  We started implementing ESXi internally, and to our dismay discovered one other feature that is missing from ESXi - the ability to clone virtual machines and to create templates.  Without cloning and templates, you lose out on one of the biggest advantage of using virtual machines, VMware or otherwise - rapid deployment.  I guess VMware wants you to purchase ESX if you need these features.

Unsatisfied with that assessment, I started digging around and came up with a procedure to be able to clone VM’s.  It’s more manual than using the ‘Clone to Virtual Machine…’ option in Virtual Center with ESX, but that’s what you pay the big bucks for - ease of management.  In a nutshell, this is what I did:

1. Build a virtual machine with your OS of choice.  *cough* Linux *cough*
2. Enable ssh into the ESX host
3. ssh into the host
4. Go into the datastore in which you created your VM
5. Make a copy of the VM you just built

There you have your template.  In order to deploy it, it’s not as bad as one might think for a manual process.

1. Go into the datastore you are going to keep your new VM.
2. Make a new directory - I always call it the same as the short name of the VM I am creating
3. Copy only the .vmdk files into the new directory you’ve created.
4. Logout, and fire up the Virtual Infrastructure Client, and create a new VM as you normally would.
5. When it asks about the disk, choose “Use an existing disk,” and select the copy of the vmdk.

The new Virtual Machine will have been created with the disk.  Boot the server up and change the network settings and customize to your heart’s content.  I’ve thrown in a sample session of creating the template and deploying it below.  Note that in you have to build the source VM first.


[root@tlf1 ~]# ssh tlfesx1
root@tlfesx1’s password:

Tech Support Mode successfully accessed.
The time and date of this access have been sent to the system logs.

WARNING - Tech Support Mode is not supported unless used in
consultation with VMware Tech Support.

~ # cd /vmfs/
/vmfs/devices/ /vmfs/volumes/
~ # cd /vmfs/volumes/datastore1/
/vmfs/volumes/4946cee9-8d78d96a-2302-00137250f7df # mkdir template
/vmfs/volumes/4946cee9-8d78d96a-2302-00137250f7df # cp -p tlfsource/*.vmdk template/
/vmfs/volumes/4946cee9-8d78d96a-2302-00137250f7df # mkdir tlfnewsrvr1
/vmfs/volumes/4946cee9-8d78d96a-2302-00137250f7df # cp -p template/sda*.vmdk newserver1/

Tags: cloning, esxi, linux, templates, virtual center, virtual machine, VMware

DNS is ubiquitous on the Internet, yet it is often misunderstood and remains a mystery to most people. As a hosting provider we administer and troubleshoot DNS issues several times per day, if not several times per hour; so we thought it would be fun and educational to write up a series of posts regarding DNS.  We’ll toss in a few tidbits and techniques of troubleshooting it, for kicks.  So without further ado!

DNS In a Nutshell

The Domain Name System (DNS) is simply a Internet-wide database for associating friendly domain names (example.com) to an IP addresses (1.2.3.4). Over time, other functions such as Domain Keys and SPF for Spam prevention have burdened DNS with a few more responsibilities–but none have fundamentally changed its primary purpose or how the system works.

The Players

To understand the DNS process one must understand the parts involved, and fortunately DNS only has a few.  On the Internet, the DNS system can most generally be segmented into three major parts:

1. Your computer.
2. The Root DNS Servers.
3. All other DNS Servers.

A few important things regarding domain names you should know…

1. The period, or “dot” in domain names is a symbolic character representing a change of authority.  For instance, one server may be responsible for the DNS database containing tlfhosting.com., and yet another might be responsible for linuxrocks.tlfhosting.com. Each time a period is seen by your computer, it knows it has to ask a server for more information.   It could be the same server, or a different one–but it is required to ask nonetheless.
2. Your computer actually “reads” domain names from right-to-left (backwards of how english is read).  Why?  It’s simply trade-off between readability by people and a logical hierarchy that computers need.   Things wouldn’t make much sense to people if we typed .com.tlfhosting.www after all.  It just looks strange, because we read things from left to right.   Yet because of how DNS is structured, your computer needs to read it that way.
3. Every domain name actually has a trailing period.  Notice how we’ve been typing “tlfhosting.com.”?  That’s actually the correct way to type it.  In fact, open a new window in your browser and type www.thelinuxfix.com. (with the trailing period).  Next try www.google.com., or any other domain for that matter.  Normally it isn’t needed, but only becase most software ‘types’ the trailing period for you automatically.  But why the trailing period?  Think of it in context of items #1 and #2 above, and it begins to make sense.

Let’s take a quick look at one of our own second-level domains (we’ll help explain that term in a moment): tlfhosting.com.   Let’s say you’d like to connect to www.tlfhosting.com. to do something–could be a website, telnet, FTP, or anything.  The important point is that to do anything your computer first needs the IP address of www.tlfhosting.com., since it cannot do a single thing with english words!

The Root Servers and TLDs

To get things started, we’ll have to talk about that all-important trailing dot on “www.tlfhosting.com.”

Remember point #2 above.  The first thing your computer sees when trying to translate the domain name is a period (.).  Because of that, it knows a domain is coming next so it will need to ask a DNS server about it.

But wait, which server?  How is it supposed to know where to look if it’s just getting started?

This is where the Root Servers come in.   The Root Servers are represented by the trailing period (.) in google.com. and tlfhosting.com., or any domain for that matter.

As you’ve probably figured out, the Root Servers are then responsible for all top-level-domains (or “TLDs”), such as “net.”, “org.”, “edu.”, and so forth.  They’re called top-level simply because all other domains (like tlfhosting) are under their authority.   So these things are not only busy–they’re very, very important to the operation of the entire Internet!

The Root Servers don’t change much at all.  In fact, most computers are already hard-wired in a programming sense to know who to ask about “com”, “net”, or any of the other TLDs.  In fact, every computer that asks something about any domain name on the Internet at some point or another asked the Root Servers a question. As you can imagine, these are busy little servers.

Now hopefully the term “Second-Level-Domain” should begin to make more sense as well.   If “.com” is a top-level domain, then logically tlfhosting.com is a second-level domain, and thus subdomain.tlfhosting.com would be a third-level domain.  It just goes right-to-left as we were talking about.  Easy as pie!

Keep an eye out for part 2, where we’ll discuss the exact process a computer follows to determine the IP address of any domain.

Tags: DNS, domain names, hosting, internet

The Linux Fix uses some pretty cool gear to run our phone system.   With some help from VMWare, an install of Trixbox here in the California office is trunked to a few Broadvoice SIP business accounts.  Internally, we use some nice Aastra 480i IP Hardphones in the office that communicate via SIP to the Trixbox PBX.

This setup provides us with inexpensive long distance, a $5.00 toll-free number, as well as the ability to do ring-groups and call forwarding to mobile phones when customers dial in and need support.

The Linux Fix also has a few people that help out and live out of state.  For one of these guys, we have established a permanent VPN setup a few months ago (with the help of a few Fortigate units) to provide them with an actual extension and ease management tasks.

Ever since we’ve had this setup, there was a nagging issue that we just couldn’t get to the bottom of.   When calling from the office->out, everything worked fine.   However, when the remotes called into the office, or try to dial out (remember, everything is trunked from the Trixbox here in California), the call would last exactly 20 seconds and then just suddenly disconnect.  Trixbox would also log something along the lines of:

“Hanging up call 699105eb51dc2bb700889eafbf955a5e@10.0.2.10 - no reply to our critical packet.”

Googling around reveals that quite a few people have at least some variation of the same problem.  After some research we finally figured it out.   It all has to do with NAT, Firewalling, and Trixbox (and thus Asterisk’s) NAT settings.  It’s a a bit hard to explain in a blog post, so hopefully these diagrams will sort it out and help explain what is going on.

The “Wrong” Way, and, The “Right”Way

Tags: 20 seconds, aastra, Asterisk, dropped calls, hangup, lost audio, sip, Trixbox, VoIP, vpn

Yesterday a few of you noticed some problems with PHP-enabled sites on the TLF servers.   We were notified about it pretty quickly, and got to work on it just as fast.

Anyway, we discovered that H-Sphere’s PHP5 support, as installed; has a bug in the php.ini files that it creates.   Since H-Sphere can support both PHP4 and PHP5 in parallel, as well as Apache 1.x and 2.x, there’s quite a bit of configuration file juggling going on.

The php.ini file for PHP5 that was in use was referring to the PHP loadable module path for Apache 1.x, and not 2.x.   For other administrators of H-Sphere, you might want to double check that this line is appropriate in your own php.ini.

For instance, our /hsphere/local/config/httpd2/php5/php.ini file had this entry:

;include_path = “.”
include_path = “.:/hsphere/shared/apache/libexec/php5ext/php/”
doc_root =
user_dir =
extension_dir = “/hsphere/shared/apache/libexec/php5ext/”
cgi.fix_pathinfo = 1

When it really should have been:

;include_path = “.”
include_path = “.:/hsphere/shared/apache2/libexec/php5ext/php/”
doc_root =
user_dir =
extension_dir = “/hsphere/shared/apache2/libexec/php5ext/”
cgi.fix_pathinfo = 1

This must have occured when we did the PHP5 upgrade, and didn’t take effect until Apache actually restarted again some time later.

Thanks for being patient during the issue!

Tags: hsphere, php.ini, php5, upgrade

After much testing, we’ve enabled PHP5 for all hosting plans.  H-Sphere implements this in a module/CGI type configuration so our users can choose between PHP4 and PHP5.   Check your settings under “Web Options” to find out which you’re using.

Part of the update included moving to a newer version of Apache as well, all went off without a hitch.

Enjoy!

Tags: hosting, PHP, shared, updates, upgrades

We recently upgraded the control panel to version 3.1, which went off without a hitch.  A nice side benefit is that we now support Ruby on Rails on all our web hosting plans.   Ruby fans unite!

Tags: H-Sphere, ruby, ruby on rails, tlf, Web Hosting

Hi everyone!  Along with the new site, we’ve launched the official TLF Blog along with our new TLF Forums.

Our goal is to ensure we stay better connected with our customers with goings on inside TLF, as well as getting news and updates regarding to The Linux Fix into your hands as quickly as possible.

Keep an eye out for posts from the other TLFers soon!

Tags: blog, launch, new, site