Web hosting for cheap on a virtual machine

The thing you have to remember about working in IT is that no two projects are ever alike.  Even if you're being asked to do the same thing for 10 different people you're still going to be surprised.  Sometimes even on the same project.

So it was with my latest foray into virtualization on the cheap.  The client could barely afford to pay me let alone invest thousands in licensing fees.  So we had to get creative without sacrificing stability. 

That can be a tall order especially when everything you're using is Open Source. 

Now I have my issues with the way the Open Source community does things but a good product is a good product regardless of who made it.

Of course, "good" is a relative term. 

It's always a trade off.  A bit of pain to save a lot of money is fair but too much pain can cost more than if you'd just went with a commercial option.  And I do mean "commercial" because I still firmly believe that any product that relies on a fractured support community or high priced "experts" to make a product work is just this side of an amateur effort. 

Not that all open source products are that way, however.  

Some communities are better than others and if they put together a solid package with "readable" documentation then I'm all for it.  If we're just stroking somebody's ego so they can get a guest spot on Floss Weekly I'll take a pass every time.

I put CentOS, the open source version of Red Hat Enterprise Linux, and Z-panel, the open source clone of C-panel squarely in the "good" category.

Together they offered a cost effective and relatively stable platform for web hosting.  Add in a virtual platform for them to live on and you've got a web host that could fit on a keychain.  Not bad...

Instead of bore you with 4000 words of text describing my latest open source virtualization adventure I've created a video that takes you from creating the virtual machine to administering your new web host. 

As you're watching you may miss a few of the links in the video.  I've provided them below.

https://www.centos.org/

http://www.zpanelcp.com/

Zpanel Docs page

Z-panel install tips
Zpanel important paths
Zpanel password reset

An ESXi host, a NAS and NFS

When you're an IT guy tinkering is part of your lifestyle.  There has to be at least a modicum of curiosity about how things work.   We drive department heads crazy because just keeping stuff working isn't good enough for us.  We want that extra Megabit of throughput or another free Gigabyte out of the SAN.

Sadly, most of us can't afford to set up an server farm in a spare bedroom just to satisfy our need to tinker; but with virtualization you can come very close.

That is of course the promise.  Being able to harness the same capabilities of a small enterprise with a lot less hardware is undeniably a good thing.  Letting us run wild in our own little enterprise is even better.

VirtualBox, VMWare Workstation and their kind is fine for taking a new OS out for a spin but they fall a bit short for giving you real world skills.

ESXi, however, is another story.  Maybe more than any other platform, it's probably the most useful and relevant virtualization lab platform you can experiment with.  Don't confuse this with your grandpa's ESXi, though. 

Starting with version 5, VMWare decided that ESXi is the one hypervisor to rule them all instead of just being ESX's little brother.  That means anything you do with ESXi translates to what you can do in the enterprise.

It's one thing to play with virtual servers in VMWare but it's quite another to play with the platform itself.   After all, the more you tinker with it the better it works right?  Well, at least till we blow something up...

So this time around I decided I wasn't satisfied just locking myself out of the VSphere Client because I forgot the password.  I wanted to get some external storage online but I didn't have a spare ISCSI array laying around.   So I decided to venture into the wonderful world of NFS.

In ESXi you've basically got 2 options for storage.

1. Local - meaning it's either physically attached to the host or on a dedicated backbone via ISCSI

2. NFS - Which is pretty much "other"

Local's easy, if your storage controller can see it so can VMWare.  ISCSi  adds a wrinkle but so long as your target's on the network it's not a big deal.

NFS, ah, that's a different story.  A lot of Sys Admins can go an entire career without having to deal with it.   Like SMB, NFS is designed to offer up access to files on a network.  Those shares are usually hosted on Unix servers but unlike SMB, NFS is designed to fool your local PC into thinking a network resource is local.  An impressive feat compared to the clunky "Map Network Drive" or CLI "Net Use" commands in Windows.

Ok, so we know what NFS is but why do we care about it for VMWare?  Simple, most NAS storage devices will have support for the protocol to allow UNIX clients to access their shares.  Set up NFS on your NAS and you've given ESXi another potential datastore to play with.

NFS has it's quirks but most NAS management interfaces make it a relatively painless process to set up.  Once that happens just be sure you have a solid network connection between your virtual host(s) and the NAS.

Follow along with the video as I set up an NFS share for ESXi 5.5, play with a VM that lives on it and even break it!

Is it a Role or a Feature?

I had an interesting experience today.  Without boring you with the details let's just say I'm no richer for the experience save for providing the catalyst for the following instructional tidbit.  The catalyst in this case was a question posed to me.  I was asked what the difference was between a Role and a Feature when configuring a Windows server.

Now most of you who have any experience at all in Windows Administration may not necessarily be comfortable with the concepts of Server Roles and Features.  It's been a slow but steady evolution from an abstract label to a shortcut in Server Manager. 

Since Windows 2000's introduction of Active Directory, the concept of a server role took on new meaning.  Instead of being limited to just designating a server as a Primary or Backup Domain controller now we had multiple roles that made the old labels moot.

Yeah, I'm talking about the most confusing collection of server "Roles" ever introduced to the Windows Universe, the FSMO or Flexible Single Master Operation.  5 labels that have confused Windows Administrators for a decade. 

I mean, the PDC emulator is fairly intuitive, for example.  We know what that's for right?  Well only partially because that role handles a lot more than just  Primary Domain Controller services for Windows NT (non AD) networks.  It also provides Time synchronization, Group Policy replication, and account lockout and password change services for an entire windows domain.  If the server that holds this role fails you're going to have a very bad day until you move it to another server.

Relative ID master?  All that does is keep all the names on your network unique.  It's function is to keep combining computer or user object Identifiers (SIDS) with a pool of unique Identifiers managed by this role (RID)  Combining the two values ensures that no two objects on an AD network are alike even if everything else about them is the same.  The RID master can't allow its pool of RIDS to go empty or it won't have anything to combine with the new SIDS that come from a new user or computer account.  Yeah, that's real obvious.

How about the Infrastructure Master?  It's a role and its function is... uhh...Oh yeah, it makes sure that if someone from one domain gets rights to something in another domain their specific information is recognized properly.  How come such a serious sounding name for such a tiny function that's so rarely used?  Whatever..

Those three roles are considered the "Domain" roles in Active Directory networks.  That means they only affect the immediate domain they serve.  There are two other roles that are considered Forest or Enterprise level roles.  That means they live at the top of your AD network above all the domains (assuming there's more than 1) that branch off of the "trunk" of your "forest". 

In case all this talk of Directories and Forests is confusing try a different metaphor.  Think of AD in the context of a Phone Book instead of a forest.  You usually have one Phone book for a town and it contains all the names and numbers of the people with phones.  Those names and numbers can be thought of as domains.

Now say your aunt Bessie changes her phone number.  The phone book is going to need to be updated to reflect the change or she'll be very lonely because nobody will be able to call her anymore.  That would be sad for Aunt Bessie and nobody wants that!

If the phone company decides to change the area code for your town then all the people listed in the phone book have to tell their out of state relatives what the new area code is or they won't be able to call them anymore.  Changing the area code, by the way, would be considered an enterprise event to the people listed in the phone book.  So would changing the name of the town by the way. 

It's the concept of changing names within an organization that leads us to the first of the two "Forest" or "Enterprise" level roles in Active Directory.  Coincidentally, it's called the Domain Naming Master and the simplest way to explain its role is to refer back to our theoretical phone book. 

Remember when Aunt Bessie changed her number?  Well she's a spry old gal and decided to get hitched up to a nice older gent.  That meant her last name changed.  To make sure everyone can find the happy newlyweds we'll need to get the phone book entry updated.  To accomplish that, she had to call the phone company and ask them to change it.  The phone company is responsible for changing Bessie's name in the phone book and they are the only ones that could do it.  If the phone company is closed nothing changes just as no domain names throughout the enterprise can change if the Domain Naming Master goes offline.

The second and final enterprise FSMO role is easier to understand since its name is a little more descriptive than the others.  It's the Schema Master and if you have any experience with databases its function will be instantly recognizable.  If you remember that all the information in Active Directory is stored in a database then you know that something has to control the way its organized.  That's the function of the Schema Master along with copying (replicating) any changes that occur to the Schema to the rest of the Enterprise. 

Going back to the phone book example, the Schema Master would be the guy who decides how the phone book is going to be organized.  Will it be sorted by name or phone number? How much information will each listing contain?  These questions are all answered by the guy printing the phone book.  He is the Schema Master.

Ok maybe not so dramatic but the Schema Master is an important Role.  Without it Active Directory couldn't exist.

I've actually went a bit deeper into FSMO roles than I planned but it's important information.  It's also important to know how Microsoft tends to overload their terminology.

In the previous discussion I've laid out what Microsoft defines as a "Role" in the context of functions that support Active Directory.  There's another definition of a server role, however, that has nothing to do with supporting Windows but rather defines services for users. 

You may have noticed that I haven't said much about "Features" to this point.  That has everything to do with Microsoft's overloaded terminology again.  In the context of an FSMO role a feature is nothing more than a facility for management of a given role.

In the context of a Server Role, however, features become very important.  A Server Role in Windows 2000 and later is designated set of services that support user activities.  Examples are File and Print services, Application Server and DNS Server roles.  Each of these roles is task based defining a set of services to be offered to users by the server. 

Server Roles can be viewed more as containers than mechanisms.  They are comprised of programs and services tailored to the support of the role.  Features are usually the programs and services that provide the functionality of the role.  Think of it as the option list on a new car.

A new car has one role, to provide transportation.  It's price, however, is dependent on the number of features it has.  A base model won't have as many amenities but will still satisfy the core requirement to provide transportation.  Many times you can specify additional equipment to tailor its function to better match your needs.  This affords additional functionality or "Features" without affecting the core requirement of providing transportation.

It's really that simple.  Roles define a task and features support it. 

That's about enough, I really don't want to write the word "Role" anymore..

:-)